HTML escape is the deliberate substitution of the five characters that participate in HTML syntax — ampersand (&), less-than (<), greater-than (>), double quote ("), and apostrophe (') — with named or numeric character references that the browser parses back as literal text. The substitution is precise: only the five syntax characters map to references, ordinary letters and digits stay readable, and the operation runs in the opposite direction for decoding. Escaping matters because these five characters are the symbols HTML uses to begin tags, end tags, separate attribute values, and declare an entity reference itself. If any of them appear unescaped inside the wrong context, the browser stops reading your data and starts reading your markup, which is the cause of broken layouts, malformed pages, and a familiar class of injection bugs. HTML escape explained, in practice, means understanding that escaping is a string transformation applied to text before it lands in HTML, not a filter applied to a finished document.
What HTML Escape Actually Means
The mechanism behind HTML escape is a fixed substitution table for the five syntax-significant characters. In basic mode the encoder replaces ampersand with &, less-than with <, greater-than with >, double quote with ", and apostrophe with the decimal reference '. Nothing else changes: ordinary ASCII letters, digits, spaces, tabs, and line breaks pass through untouched, so a paragraph of normal text emerges almost identical to what went in. Two implementation details decide whether the table behaves correctly. First, ampersand must be replaced before any other replacement runs, because every other reference in the table begins with an ampersand. If less-than were escaped first to <, a subsequent pass over the ampersand would see a freshly created & and re-encode it, producing the doubled sequence &lt;. Second, the encoder iterates Unicode code points rather than UTF-16 code units. That distinction becomes visible on supplementary characters such as 😀 (U+1F600): code-point iteration produces one reference 😀, while naive UTF-16 unit iteration would emit two invalid surrogate references. Modern UTF-8 HTML documents can hold such characters directly, so MDN advises avoiding unnecessary numeric references for readability.
Encode vs Decode: Two Sides of the Same Operation
The HTML Entity Encoder / Decoder exposes two complementary operations. Encode converts literal characters into HTML character references and protects only the five syntax-significant characters, leaving the rest of the text readable. Decode runs in the opposite direction and is broader than the encode table: a detached textarea element asks the browser's HTML parser to resolve every named, decimal, and hexadecimal reference the WHATWG HTML Living Standard currently defines. That table includes legacy aliases and references that map to more than one code point, so a string such as © decodes to © even though the encoder would never have produced that reference in the first place. Decode returns plain text into a read-only field. The decoded value is not inserted into the visible page or executed as markup; it is just text waiting to be inspected and copied into a context-appropriate place.
The Five Reserved Characters in HTML Syntax
The basic encoding table is short on purpose. These five characters are the only inputs that change hands with the parser, so they are the only inputs that need protection.
| Literal character | Basic-mode reference | Role in HTML syntax |
|---|---|---|
| & | & | Introduces every entity reference |
| < | < | Opens a start tag |
| > | > | Closes a start tag |
| " | " | Delimits a double-quoted attribute value |
| ' | ' | Delimits a single-quoted attribute value |
A non-ASCII mode performs the same five replacements and additionally converts every code point above ASCII 126 to an uppercase hexadecimal numeric reference. That mode exists for legacy or transport workflows where a numeric-reference representation is genuinely required, not for everyday readability.
How to Encode or Decode Text in the Browser
- Pick a direction — Encode characters or Decode references — and, when encoding, choose between basic and non-ASCII mode.
- Paste the source text into the input field. The tool accepts up to 500,000 JavaScript characters per operation.
- Run the conversion so the output panel populates with the transformed string.
- Inspect the result for the five reserved characters (in encode mode) or for unexpected markup-looking text (in decode mode).
- Copy the result only into a context that matches what the transformation prepared it for, such as a text node, an attribute value, or a static documentation page.
For a quick check before pasting a large block, run a small representative sample first and confirm that ampersands and angle brackets look right. The page does not save history, fetch a remote entity table, or transmit the input, so what you see is exactly what your browser computed.
Why Escaping Is Context-Sensitive, Not Context-Proof
HTML escape protects the five syntax characters of an HTML document. It does not protect any other syntax. A string that is safe to place inside a paragraph may not be safe inside a URL parameter, a JavaScript string literal, a CSS value, an SQL query, or an HTTP header, because each of those grammars uses its own delimiters. The WHATWG HTML Living Standard is the authoritative source for the named reference table, and MDN's character reference glossary documents how those references resolve. Treating the tool as a sanitizer is a category error: it escapes characters in a string, but it cannot stop a finished document from being rendered in an unsafe sink. Decoding can reveal markup-looking text — <script> becomes the literal characters <script> — and the decoded string, if pasted into an innerHTML sink, would still execute. Treat decoded output as untrusted and apply context-aware escaping at the final output boundary.
Where HTML Escape Stops Being Enough
Three boundaries are worth naming up front. First, XML has a much smaller predefined entity set than HTML, so a reference such as © that decodes correctly here may fail validation in an XML pipeline. Second, framework auto-escaping and trusted templating engines already produce correctly escaped output from typed values; running this tool over their output is redundant at best and, if the templates intentionally embed HTML, broken at worst. Third, a Content Security Policy is a separate defence against script execution and cannot be replaced by string-level escaping. The encoder does not replace every printable character with a named entity either, because modern UTF-8 HTML can carry Unicode directly and unnecessary references make source harder to read.
The tool is the right fit when you have raw text that must travel through HTML, when you are reading a configuration or template that mixes literal and encoded segments, or when you need to inspect a string before deciding where it belongs. For readers who want a printable summary of the reserved characters, the HTML Escape Cheat Sheet: Reserved Characters guide collects the same table alongside the contexts where each escape is necessary.
Related reading: Free 16-Character Password Generator That Runs Locally.