Security & devFree
Free HTML encoder and decoder. Escape or unescape HTML entities (< > & quotes) for safe snippets. Runs locally in your browser.
Last updated 14 October 2026
Encode replaces &, <, >, " and ' with their entities and leaves every other character as it found it. Measured: those five together come back as &<>"', and café 🎉 comes back as café 🎉, unchanged.
That is the right set for the job. Those five are the characters that can end an attribute, open a tag or start an entity, so escaping them is what stops text being read as markup. Accented letters and emoji are ordinary text to an HTML parser and do not need escaping at all, as long as the page declares UTF-8, which every modern page does.
So if you were expecting é to become é, it will not here. That style of encoding was a workaround for pages in older character sets and is not needed today. A non-breaking space is also left as the invisible character it is, rather than converted to , which matters if you are trying to find out why your layout has a gap in it.
The two directions are not mirror images. Decode hands your text to the browser’s own HTML parser, which knows the full list of named character references, so it decodes far more than encode creates. Measured: © — é decodes to © — é.
That is useful, and it has one consequence to plan for. Encode then decode always gets you back where you started. Decode then encode may not. If you decode text containing — you get a real dash, and encoding that dash gives you the dash again, not the entity. The entity is gone for good. Keep your original if you need it.
Measured: ¬anentity; decodes to ¬anentity;. There is no such entity as notanentity, so you would expect the text back unchanged. What happens instead is that the HTML parser matches the shortest thing it recognises, ¬, which is a legacy named reference that works without its semicolon, and decodes that to the logical-not sign. The rest of your text, anentity;, is left sitting after it.
This is in the HTML standard, not a browser quirk: a set of named references from the early web are still matched without a trailing semicolon, for compatibility with pages written against the old rules. The practical lesson is that half-escaped text is more dangerous than unescaped text, because the result can be a silent corruption rather than a visible error. If text has been through an encoder once, do not guess whether it needs decoding; find out.
Each pass peels exactly one layer. Measured: &lt; decodes to <, and decoding that again gives <.
Double-encoded text like that usually means a value passed through two systems that each escaped it, and seeing & in a page is the signature. Press decode once per layer. There is no “decode until nothing changes” option, deliberately, because that would also decode text that genuinely contained the characters &, a, m, p, ;.
This is worth being direct about, because it is the reason people arrive here. Encoding these five characters is correct and sufficient for putting text into an HTML page: the result cannot open a tag or close an attribute, so it is displayed rather than executed.
It is not a way to sanitise HTML you want to keep as HTML. If you need to accept some markup from someone and allow a few tags through, escaping is the wrong tool entirely and you need a real sanitiser with an allow-list. Escaping is also context-dependent: text going into a URL, into JavaScript, or into a CSS value needs that context’s escaping, not this one. The OWASP cheat sheet cited below is the short version of which context needs what.
On the decode side: pasting a script tag into this tool is harmless. Measured, with the browser console watched, <script>alert(1)</script> decodes to that same text and nothing runs, because the decoded value is only ever read back as text and never inserted into the page as markup. That is a statement about this tool, not about whatever you paste the result into afterwards.
Nothing is uploaded. Both directions run in your browser and the text never leaves your device.
Every behaviour and every decoded string on this page was measured against this tool as it is published, in a browser, on 14 October 2026. Where the page says what the tool does not do, that is a statement about this tool, not about HTML escaping in general.
Because it does not need to. An accented letter is ordinary text to an HTML parser on a UTF-8 page, which is every modern page. Only five characters can change the meaning of markup, &, <, >, " and ', and those are the five this tool escapes. Entity names for accented letters were a workaround for older character sets.
Because the HTML standard still matches a set of early named references without their semicolon, and ¬ is one of them. The parser takes the match it recognises, turns it into the logical-not sign, and leaves anentity; behind. It is specified behaviour, not a browser bug, and it is why half-escaped text is worse than unescaped text.
Because decoding uses the browser’s own HTML parser, which knows every named character reference, while encoding only escapes the five structural characters. So encode then decode always round-trips, but decode then encode may not: once — has become a real dash, encoding gives you the dash back, not the entity.
Your text was encoded twice, which usually means it passed through two systems that each escaped it. Each press peels one layer: &lt; becomes <, and pressing again gives <. There is deliberately no decode-until-stable option, because that would also mangle text that genuinely contains an ampersand.
For putting plain text into an HTML page, yes, that is exactly what escaping these five characters achieves. For accepting HTML from someone and keeping some of it as markup, no, you need a real sanitiser with an allow-list. And text going into a URL, a JavaScript string or a CSS value needs that context’s escaping instead. The OWASP cheat sheet linked above is the short version.
Yes. We measured it with the browser console open: the decoded value is only ever read back as text and never inserted into this page as markup, so nothing runs. That is a statement about this tool, and says nothing about wherever you paste the result afterwards.
No. Encoding makes tags visible as text instead of being interpreted, which is usually what people actually want, but the characters are all still there. Nothing here strips, validates or tidies HTML.
No. Both directions run in your browser, there is no request carrying your text off the page, and nothing is saved, so refreshing loses it.