HTML Entity Escaper
How to use this HTML entity escaper
- Paste HTML or plain text into the input box.
- Choose "Escape" to convert special characters to entities, or "Unescape" to reverse it.
- The result updates instantly on the right.
Why escape HTML entities?
Characters like <, > and & have special meaning in HTML. Escaping them (turning < into <, for example) lets you display code snippets or user-generated text safely, without the browser interpreting them as actual markup.
Does this prevent XSS attacks?
Escaping is one important layer of defense against cross-site scripting, but a complete security strategy also needs proper input validation and context-aware output encoding on the server side.
What's the difference between ' and '?
Both represent an apostrophe. ' is the numeric entity supported everywhere, while ' is a named entity that older versions of Internet Explorer didn't fully support in HTML (only XML).
Why exactly five characters need escaping in HTML
An HTML parser reads a document as a stream of markup, and only a small number of characters actually change how it interprets what follows — which is exactly why escaping focuses on just those. "<" opens a tag, so an unescaped "<" in text content risks being read as the start of an element the author never intended. "&" begins a character reference (an entity like "&" itself), so a literal ampersand needs escaping to avoid being misread as the start of one. Quote characters (" and ') matter specifically inside attribute values, where they mark where the attribute's value ends — an unescaped quote inside quoted attribute text can prematurely close the attribute and let the following text be interpreted as new markup instead of data. Everything else in ordinary text content needs no escaping at all, which is why over-escaping (encoding characters that don't need it) mostly just adds visual noise rather than actual protection.
Named entities versus numeric character references
HTML actually offers two different ways to represent the same escaped character, and both are valid, though they serve slightly different purposes. Named entities like &, <, and © are easier for a human reading the raw HTML source to recognize at a glance, but only a specific, defined set of names is supported, and support has historically varied slightly between HTML and XML/XHTML parsing rules. Numeric character references, either decimal (') or hexadecimal ('), can represent any Unicode code point at all — not just the specific characters that happen to have a named entity — which makes them the more universally reliable choice for escaping arbitrary text programmatically, even though they're less immediately readable to a human scanning the raw markup.
Why escaping alone is necessary but not sufficient against XSS
HTML-escaping untrusted text before inserting it into a page is a genuinely essential defense against cross-site scripting, but treating it as a complete solution is a common and dangerous oversimplification. The correct way to escape a piece of data depends entirely on exactly where it's being inserted — text that's properly HTML-escaped for placement inside an element's body content can still be dangerous if inserted directly into a JavaScript string, a URL, or a CSS value instead, each of which has its own, different set of characters that carry special meaning and its own separate escaping rules. This is why real-world security guidance talks about "context-aware output encoding" rather than just "HTML escaping" — the correct escaping approach must match the specific context data is being placed into, not a single one-size-fits-all transformation applied everywhere regardless of context.
The double-escaping mistake, and how it happens
Double-escaping is a frequent, purely cosmetic but genuinely annoying bug where text gets HTML-escaped more than once, causing entities themselves to become escaped — turning "&" into "&amp;", which then displays literally as "&" on the page instead of the intended "&". This typically happens when escaping is applied at more than one layer of an application without anyone tracking it carefully — for example, a templating engine that automatically escapes all output by default, combined with application code that also manually escapes the same value before passing it to the template, unaware the template will escape it again. The fix isn't escaping more carefully — it's escaping exactly once, at the single point where trusted and untrusted data actually meet the output context, and being disciplined about not escaping earlier or later than that one point.
Limitations of this tool
This tool escapes and unescapes the standard set of HTML-significant characters (<, >, &, and quote characters) for safe placement inside HTML body content — it doesn't perform the different escaping needed for other contexts like inside a <script> block, a CSS value, or a URL, each of which has its own distinct rules as explained above. It's a text transformation utility, not a substitute for a proper templating engine's automatic, context-aware output encoding or for server-side input validation — use it for quickly displaying code snippets or debugging escaped text, not as your application's sole XSS defense.