HTML Escape/Unescape
Max 256 KB · Updates automatically as you type
HTML reserves a handful of characters for its own syntax: < and > open and close tags, & starts an entity reference, and "/' delimit attribute values. Any of those characters appearing literally in text that gets inserted into a page — a comment, a form value, a URL fetched from elsewhere — risks being parsed as markup instead of displayed as data. That’s not just a display glitch: an unescaped <script> tag in user-supplied content is the textbook mechanism behind cross-site scripting (XSS). Escaping neutralizes the risk by converting each of those five characters into its entity form — a &-prefixed, ;-terminated sequence that every browser renders back to the original character on screen, but never interprets as markup.
The five characters this tool escapes are & → &, < → <, > → >, " → ", and ' → '. This is the standard “HTML-injection-safe” set — the same five most templating engines and frameworks escape automatically for you, and the minimum needed to make arbitrary text safe to place inside an HTML document. One ordering detail matters: & is always escaped first. Since every entity reference itself begins with &, escaping the other four characters first and & last would double-escape the ampersands those replacements just introduced — turning < into < and then into &lt;. Escaping & before anything else avoids that entirely.
Unescaping reverses the process, and handles three different reference formats. Named entities like & or are looked up by name — this tool recognizes the five core safety entities plus a common subset of roughly two dozen more (typographic punctuation, ©/®/™, currency symbols) rather than the full HTML5 table of over 2,000 names, most of which are obscure mathematical or symbol glyphs no real-world paste is likely to contain. Decimal numeric references like ' specify a Unicode code point directly in base 10, and hex numeric references like 😀 specify the same thing in hexadecimal — both are decoded in full regardless of which character they represent, since they don’t depend on a name lookup at all. Anything that doesn’t match one of these three well-formed shapes — a reference missing its semicolon, an unrecognized name, an invalid number — is left untouched in the output rather than guessed at or rejected outright.
Both directions are pure text transforms with no size limit beyond the 256 KB input cap that keeps re-processing responsive on every keystroke, and no data ever leaves your browser.
Examples
- Displaying user-submitted text safely — a comment or bio field containing "<b>bold</b>" should render as literal text showing the tags, not as actual bold formatting (or worse, execute if it were a <script> tag); escaping it first with this tool shows exactly what a template engine's auto-escaping would produce.
- Unescaping HTML scraped from a page or API response — text pulled from a website's markup or a JSON API often arrives with entities like &amp; and &#8217; still encoded; unescaping it back to plain text (&, ') makes it readable and safe to re-process.
- Pairing with other codecs on the same pasted content — HTML-escaped text can still contain characters that need URL Encode/Decode or Base64 Encode/Decode treatment before it's embedded elsewhere (a query parameter, a data URI); run it through whichever encoding actually matches where the text is headed.
Frequently asked questions
Why does an entity need to be escaped before it can go inside HTML?
< and > to mark the start and end of a tag, & to start an entity reference, and "/' to delimit attribute values. If any of those five characters appear literally inside text that's inserted into a page — a username, a comment, a URL — the browser can misread them as markup instead of data. That's the core mechanism behind stored/reflected cross-site scripting (XSS): an unescaped <script> in user-supplied text becomes a real, executing script tag. Escaping converts each character to its entity form (<, &, etc.), which displays identically but can never be parsed as markup.Why is & escaped first?
& — <, ", and so on. If < were escaped to < before & was handled, the escaper would then encode the & it just introduced, producing &lt; instead of < — a corrupted, double-escaped result. Escaping & first, before any of the other four characters, guarantees the entities produced by this step are never themselves re-escaped.Which named entities does the unescape direction understand?
&, <, >, ", ') plus roughly two dozen of the most common named entities found in real-world pasted or scraped HTML — , typographic punctuation like — and “, ©/®/™, and a handful of currency and math symbols. The full HTML5 named-entity table has over 2,000 obscure entries; this tool covers the common subset rather than reproducing all of it. Decimal ({) and hex (😀) numeric references are decoded in full, regardless of which character they represent, since those don't rely on a lookup table.What happens if I unescape text with a malformed or unrecognized entity?
&), an unrecognized name (&foo;), or an invalid numeric value is not something this tool can confidently resolve, so rather than guess — or throw an error and block the rest of the output — it passes that fragment through unchanged and continues decoding everything else.