HTML Entity Encoder & Decoder

Escape or unescape HTML as you type — named, decimal or hex. Runs entirely in your browser.

← Back to the URL Encoder

Also searched as html encode · html escape · html entities · escape html · html entity decoder · html special characters. It is one tool: text to HTML entities, and back.

Everything runs in your browser. Nothing you type is uploaded to any server.

1Escape or unescape

Pick a direction, type or paste, and the result updates live.

Direction
Entity style
Characters to escape
Non-ASCII characters
Escaping text into HTML entities. Switch to Decode to turn entities back into text.

2Live: what the encoder is actually doing

An HTML entity is a way to write a character using only ASCII. The style decides how it is spelled, and the character set decides which characters are touched at all. This readout shows the choice being made.

Mode
Encoding
Entity style
Named
Escaping
& < >
Non-ASCII
kept
Entities in output
0
Output length
0
CharacterCode pointEntityKind
Type something above to see how each character becomes an entity.

3HTML entities are not URL encoding

This is the part almost every HTML-escape tool skips. HTML entities and percent-encoding (URL encoding) are two different systems that happen to both turn awkward characters into ASCII. They escape different characters, they live in different places, and they are decoded by different things. Using the wrong one does not just look wrong — it changes the value.

Comparison: less-than becomes the HTML entity &lt; in HTML, or %3C when encoded as URL data.
Choose the escape format for the parser that will read the value.
Your input —
HTML-escaped (for HTML) —
Percent-encoded (for a URL) —
Which one you want —
HTML entityPercent-encoding (URL)
What it escapes characters that have meaning in HTML markup — & < > " ' characters that are not safe in a URL — space, & ? # / = +, all non-ASCII
Looks like &amp; &#38; &#x26; %26 %20 %3D
Applies inside an HTML document: text, attributes, <title>, comments, email HTML a URL: query values, path segments, form fields, redirect targets, href values
Decoded by the HTML parser (the browser when it renders the page) the server / HTTP stack when it parses the request line and query string
& becomes &amp; — so the parser does not read it as the start of an entity %26 — so the server does not read it as the next query parameter
Example &lt;b&gt; renders as the text <b> a%3Db%26c arrives at the server as the value a=b&c

&amp; is not %26

HTML entity &amp; is HTML's spelling of the character &, read by the browser while rendering
Percent-encoding %26 is URL's spelling of the character &, read by the server while routing the request
Same character, different system putting &amp; in a URL does not give the server an ampersand — it gives it the literal text &amp;

Hex entities look like percent-encoding — they are unrelated

HTML hex entity &#x26; — starts with &#x, ends with ;
Percent-encoding %26 — starts with %, no semicolon
Trap because both are "a hex number for a character", people write %x26 or &#%26; — both are invalid in either system
Fix pick the system by where the value is going, not by the character

The & between query parameters

In a URL ?a=1&b=2 — the & really is the parameter separator
In HTML source that same link should be written href="?a=1&amp;b=2", so the HTML parser hands the browser the URL ?a=1&b=2
Why it bites if you HTML-escape a URL and then also percent-encode it, or do it twice, the server receives a=1%26b=2 as a single value instead of two parameters
Fix percent-encode the values, keep the structural &, then HTML-escape the whole attribute once

Order of operations: URL-encode first, then HTML-escape

You have user text that must go into a link inside an HTML page
Right order percent-encode the value for the URL → build the URL → HTML-escape the finished URL for the attribute
Wrong order HTML-escape first, then percent-encode — you end up encoding the &amp; itself and the link is double-encoded
Rule the innermost layer is applied last: the URL lives inside the HTML, so encode the URL first

Decoding the wrong system

A server receiving ?q=&lt;b&gt; does not turn it back into <b> — HTML entities are not its job
A browser rendering %3Cb%3E shows the literal text %3Cb%3E — percent-encoding is not its job either
Fix decode with the same system that encoded it, in the reverse order

When to use which

Use HTML entities when the text will be rendered as HTML markup: user comments, CMS content, form input shown back to a user, values placed inside attributes, and any string you are assembling into an HTML document or an HTML email.

Use percent-encoding when the text will be part of a URL: query-string values, path segments, form data, redirect targets, and any value you place into an href, src, or action.

Use both — in the right order — when user text goes into a link on a page: percent-encode for the URL first, then HTML-escape the finished URL for the attribute. That is the only case where the two appear together, and the order is what keeps the link intact.

No login · Unlimited use · No watermark · Runs only in your browser. This tool converts exactly once, with the entity style and character set you choose, and shows you both while it works.

HTML Entities vs URL Encoding: Same Characters, Different Contexts

Learn when to use HTML entities and when to percent-encode URL components, including the correct order when a URL is written into HTML markup.

Watch on YouTube

Related tools

Every tool on this site runs entirely in your browser. Pick the encoding problem you have:

URL Encoder / Decoder UTM Builder Base64 Encoder / Decoder JWT Decode URL Encoding in JavaScript What Is Percent-Encoding?