HTML Entity Encoder / Decoder
Escape or unescape HTML entities like & and <.
Why Escape HTML Entities
Characters like <, >, and & have special meaning in HTML. Encoding them as entities lets you display code samples or user input without the browser interpreting it as markup — which also helps prevent cross-site scripting. Named-entity mode outputs human-readable references like © and — for all 2,000+ HTML5 entities. Decoding reverses the process, supporting both numeric and named entities, all processed locally.
Built and maintained by Meet Shah · Last updated
What this tool is used for
- Making a code sample display as text rather than being parsed as markup by the page around it.
- Escaping user-supplied content before it goes into an HTML attribute or a template.
- Decoding entities out of scraped markup to recover the text a reader would actually see.
- Putting a literal `<` or `&` into documentation without the renderer swallowing it.
- Checking whether double-escaping is why `&amp;` is showing up on a page.
How it works in practice
A worked example
A snippet of copy with a name, a quotation and some punctuation has to go into a template, and you are deciding between the two encoding styles.
Tom & "Jerry" — café ©
numeric, default Tom & "Jerry" — café © numeric, all non-ASCII Tom & "Jerry" — café © named entities Tom & "Jerry" — café ©
The default touches five characters and nothing else, which is the right amount for a UTF-8 page: the ampersand and the quote marks are the ones that change how surrounding markup parses, and the dash, the accent and the symbol are just text. The second row escapes everything above ASCII, which is what you want when the output has to survive a pipeline that might mangle bytes. The third produces the same result in named form, which is more readable in source and slightly longer on the wire.
The edge case that catches people
Decoding accepts entities that have no semicolon, and the results can be startling. A named reference followed immediately by ordinary letters is still recognised, so a string that looks like one unfamiliar entity decodes to a symbol with the rest of the letters trailing behind it — the negation sign followed by a stray it and a semicolon, in the case of the obvious example. HTML5 requires this for a list of legacy references, so a parser that refuses would be the one behaving incorrectly. It means a decode is not always reversible.
When not to use this tool
Never on the way in. Decoding is for reading something — recovering the text out of scraped markup, or working out why a page is showing an entity to its reader — and running stored input through it to tidy it up re-arms whatever was escaped, turning an inert escaped script tag straight back into a live one. Escaping belongs at the moment of output, in the template, in the context the value is landing in, which is also the only place that knows whether it is going into text, an attribute or a URL.
Frequently Asked Questions
- Which characters actually have to be escaped?
- In text content, only `&` and `<` are strictly required. In an attribute value you also need the quote character you delimited with. Everything else is optional — but escaping `>`, `"` and `'` as well is the safe habit, because markup gets moved between contexts.
- Why ' instead of '?
- `'` is defined in XML and HTML5 but *not* in HTML 4, so it fails in genuinely old parsers while the numeric `'` has always worked. That is why sanitiser libraries emit the numeric form, and why you see it in output from almost every framework.
- What is the difference between named and numeric entities?
- Named entities (`©`) are a fixed list — HTML5 defines around 2,200 — while numeric ones (`©` or `©`) can express any code point. Numeric is the safer choice for anything beyond the common few, since a misspelled name renders literally.
- Should I escape all non-ASCII characters?
- Not for a modern UTF-8 page — é is fine as itself and is one byte cheaper in three. Escape everything only when the output must survive a pipeline that is not UTF-8 clean, such as an old email system or a database column declared as latin1.
- Is escaping enough to prevent XSS?
- Only in the context you escaped for. HTML-escaping a value that lands inside a `<script>` block, a URL attribute, or a CSS rule does not protect you — `javascript:` in an `href` survives escaping untouched. Escape for the destination, and prefer a real sanitiser for HTML input.
Common errors and gotchas
- Escaping only `<` and `>`. Inside an attribute, quotes and ampersands matter just as much, and leaving them open is an injection route.
- Double-escaping content that was already escaped, which shows the entity itself to the reader instead of the character.
- Using `'` and assuming universal support. The numeric form is the safe one and works everywhere.
- Escaping every non-ASCII character, which bloats the markup and is unnecessary on a UTF-8 page.
- Treating escaping as complete XSS protection. It is context-dependent, and script or URL contexts need entirely different handling.