Developer HTML encoder and decoder
Escape the five characters that break HTML, or decode any named or numeric entity back to plain text.
Ready. Runs locally on your device.
Your files stay on your device. The tool works directly in your browser, using your device to process your files. Nothing is sent to our servers, and we never receive, store, or see your files or figures.
Share result
Cite
Cite this page
Reembun. (2026, July 28). HTML encoder and decoder. https://reembun.com/html-encoder
How to use it
Pick a direction
Encode turns characters into HTML entities. Decode turns entities back into the characters they stand for.
Paste the markup or text
Encoding is what lets you show a tag on a page instead of running it, which is also what stops user text becoming an injection.
Decide how far to go
Also escape non-ASCII converts accented letters and symbols into numeric entities, for templates that cannot be trusted to stay UTF-8.
Copy the output
Copy takes the converted text, ready to paste into a template or a CMS field.
The five characters
| Character | Named | Numeric | Why it matters |
|---|---|---|---|
& | & | & | Starts every other entity |
< | < | < | Starts a tag |
> | > | > | Ends a tag |
" | " | " | Ends a double-quoted attribute |
' | ' | ' | Ends a single-quoted attribute |
Note that ' has no widely-supported named form in HTML 4, since ' is XML and HTML5 only, which is why ' is the safe choice.
Order matters
The ampersand must be escaped first. Escaping < to < and then escaping ampersands turns it into &lt;, which displays as the literal text < rather than a less-than sign.
Wrong: < → < → &lt; displays as "<"
Right: & first, then the restDouble-encoding is the most common bug in hand-rolled escaping, and it usually appears as visible entity text on a page.
Escaping is context-dependent
HTML escaping protects HTML contexts. It does nothing for the others, and using it in the wrong place gives false confidence.
| Context | Correct encoding |
|---|---|
| HTML text | HTML entities |
| HTML attribute value | HTML entities, quoted attribute |
| URL parameter | Percent encoding |
| JavaScript string | JavaScript string escaping |
| CSS value | CSS escaping |
Inside a <script> block | Do not interpolate at all |
A value that is HTML-escaped and then placed inside an onclick attribute is still exploitable, because the browser decodes the entities before the JavaScript parser sees the result.
The reliable defence is a template engine that escapes automatically and knows the context. Every modern framework does this, and the vulnerabilities that remain are almost always in the places where developers deliberately bypassed it.
Decoding
Decoding here uses the browser’s HTML parser rather than a lookup table. The specification defines more than 2,000 named references, including obscure ones like …, , — and a long tail of mathematical and Greek symbols.
The parsing happens by assigning to a textarea element’s innerHTML and reading back its value. That element type is used specifically because its content model is raw text, so markup inside it parses but never executes, so decoding a string containing a script tag is safe.
Non-ASCII characters
The “also escape non-ASCII” option converts everything outside printable ASCII into numeric references:
Café → Café
日本 → 日本
🎉 → 🎉This is rarely necessary with a correct <meta charset="utf-8"> declaration, which every modern page should have. It remains useful when output lands somewhere with an unknown or unreliable charset: legacy email templates, some CMS fields, and systems that mangle bytes above 127.
Common questions
Which characters actually need escaping?
Five: & < > " and '. The ampersand is first because it starts every other entity, so it must be escaped before the rest or you get double-encoding. The two quote characters only matter inside attribute values, but escaping them unconditionally is simpler and harmless.
Is escaping HTML enough to prevent XSS?
No. It is necessary in HTML text and attribute contexts and insufficient everywhere else. Text going into a JavaScript string, a URL, a CSS value or an event handler attribute each needs a different encoding. Context-aware output encoding, ideally from your template engine, is the actual defence.
Why does decoding here handle every named entity?
Because it uses the browser's own HTML parser rather than a lookup table. There are over 2,000 named references in the HTML specification, and a hand-written map inevitably misses some. The parsing is done in a textarea, which parses markup without executing anything.
What is the difference between named and numeric entities?
Named entities like & are readable; numeric ones like & work for any character without needing a name. Named entities outside the core five are inconsistently supported in XML and some older parsers, so numeric references are the safer choice for anything non-ASCII.
Last reviewed
