HTML Entity Encoder and Decoder

What are HTML entities?

HTML entities are the escaped stand-ins a page uses for characters that would otherwise be read as markup. Write a literal less-than sign in the middle of a paragraph and a browser tries to parse it as the start of a tag; write its entity instead and the browser prints the character on screen without ever mistaking it for code. The same idea runs in reverse: a page full of entity references is hard for a person to read, and decoding turns them back into the plain text they represent.

You need to escape text any time content you did not fully control is about to sit inside HTML. The clearest case is a user's own words landing on a page — a comment, a display name, a search term echoed back — where a stray ampersand or angle bracket could otherwise be read as the start of a tag or attribute. Code samples are the second common case: showing a snippet of markup on a page means escaping the very characters that make it markup, or the browser renders the sample instead of displaying it. Pasting into a content management system that silently mangles special symbols is the third — encoding first means what you see in the editor is what survives the trip.

This tool handles both directions of that job — encoding text for safe display, and decoding entity references back into characters — without sending anything to a server.

How to use the HTML encoder and decoder

1. Pick Encode or Decode. The switch at the top decides whether the tool escapes special characters going in or turns entity references back into text coming out.
2. Type or paste into the left pane. When encoding, choose whether the text is headed for element text, an attribute value, or the safe default, and turn on hex references or non-ASCII escaping if either applies.
3. Read the result on the right. Check the count of escaped characters or found references, watch for the warning panel if a decoded result still contains a tag, and use the copy button once the output looks right.

Why encoding depends on where the text lands

Encoding looks like it should have one universal answer, but it has a small, exactly-specified one that varies by destination. Only five characters ever need escaping in HTML at all: the ampersand, the two angle brackets, and the two kinds of quote. Which ones actually matter depends on where the string is going. Text sitting between tags only needs the ampersand and the less-than sign handled — nothing reads a stray quote there as anything special. Text inside an attribute delimited by a quote only needs the ampersand and that specific quote character escaped, because the delimiter is what closes the attribute early, not the angle brackets around it.

That distinction is also where the trap sits. Escaping correctly for an attribute value leaves the angle brackets alone, because they are legal characters inside a quoted attribute and escaping them would be unnecessary work. But leaving them alone means the escaped string still contains a live tag if one was in there to begin with. Encode a bold tag wrapping the word “hi” in attribute mode and the output still contains that opening and closing tag, unescaped; hand that string to anything that goes on to parse it as HTML and the tag disappears into markup, leaving just the word “hi” behind. The escaping was correct for its stated purpose and dangerous the moment that purpose changes underneath it — which is exactly why this tool defaults to escaping all five characters, the safe superset that stays safe wherever the string ends up.

One more detail matters once the input stops being plain ASCII: encoding walks whole characters, not the two-part units JavaScript stores some of them in internally. An emoji becomes a single numeric reference rather than being split into two separate halves that no HTML parser would know how to reassemble — the kind of subtle corruption that only shows up once the escaped text comes back out the other side broken.

Why decoding is the direction to be careful with

Decoding has a much bigger answer than encoding does, because the HTML standard defines 2,231 named character references, from the common ones to obscure mathematical symbols. Shipping that entire table to every visitor means shipping it again every time the standard adds to it, so this tool decodes through the browser's own HTML parser instead — the same implementation that decides what any real page on the visitor's machine renders, at no extra download cost at all.

That choice is also what gets three specification behaviours right that a hand-written decoder tends to get wrong. Numeric references between hexadecimal 80 and 9F are remapped rather than taken literally: the reference for decimal 128 does not produce the character actually at that code point, it produces the euro sign, because those values were historically Windows-1252 byte codes and the standard preserves that history rather than the literal number. A fixed legacy list of named references also works without a closing semicolon, purely for compatibility with older pages, while the rest of the table requires one — which is why the ampersand's own short reference decodes even unterminated, and why the standard's own example of the word “not” followed by “it” and a semicolon decodes to a not sign followed by the plain letters i, t, and a semicolon, rather than anything resembling the word “not”. And a name the standard does not define is left exactly as written, never guessed at or partially matched.

Decoding is also the direction to treat as dangerous, because escaping existed in the first place to stop a tag from being read as a tag, and decoding is precisely the operation that can put it back. This page never renders a decoded result — it is always shown as plain text — and it displays a warning whenever what comes out the other side contains something that looks like a tag, so nothing here quietly hands back live markup without saying so first.

Why is it free?

Every part of this runs on your own machine: typing into the input pane triggers a JavaScript function in your browser, not an upload to a server somewhere. Nothing you paste in ever leaves the tab, so there is no file size limit driven by bandwidth and no reason to make you create an account before you can use it.

There is no watermark on the output, no usage cap, and no sign-up wall, because none of those things do anything for a tool that never touches a server in the first place. It is free the way a calculator built into a page is free — the computation was always going to happen locally, so there was never a cost to charge for.