HTML Escape

There are two reasons to escape HTML, and they arrive from opposite directions. Either you want to show markup on a page — a code sample, a tag name in documentation, an angle bracket in a comparison — and the browser keeps rendering it instead of displaying it. Or you are inserting text you did not write into a page, and you need to guarantee that a <script> in that text stays inert. Both are solved by the same operation: turn the characters that mean something to the HTML parser into entities that do not.

This tool escapes the minimal correct set by default — &, <, >, " and ' — which is precisely the set that can break out of text content or an attribute value. Nothing else is touched, so accented letters, CJK text and emoji pass through as themselves. An optional mode escapes every non-ASCII character as well, which some legacy pipelines still want. Encoding is done by the html-entities library at html5 level, in a Web Worker on your device.

Why the minimal set is the correct set

Five characters can change how an HTML parser reads a document. Escaping those five is a complete defence against HTML injection in text content and quoted attributes. Escaping more adds bytes, not safety.

• & → &. Must go first, otherwise the ampersands introduced by the other replacements would themselves be escaped, producing < where you meant <.
• < → <. The character that starts a tag. On its own, escaping this prevents most injection.
• > → >. Not strictly required in text content, but escaping it avoids accidentally closing a tag when content is concatenated, and costs nothing.
• " → " and ' → '. These matter inside attributes. An unescaped quote closes the attribute early, after which the attacker is writing attributes rather than data — which is how onerror= handlers get injected.

The apostrophe comes out as the named reference ', because encoding runs at html5 level and HTML5 defines that name. One caveat worth knowing: ' was not defined in HTML 4, so if your output is destined for a genuinely ancient parser, substitute the numeric form ', which every parser has always understood. In XML and HTML5 both forms are correct.

Because only these five change, the output stays readable. Café < 5 becomes Café < 5 — the accent is untouched, which is what you want on any modern UTF-8 page.

Escaping every non-ASCII character: a legacy habit

The optional mode converts every character above ASCII into a named or numeric entity: café becomes café, an em dash becomes —, and CJK text becomes a long run of numeric references. It was standard practice in the 1990s, when a document's encoding was frequently unknown or wrong and entities were the only way to be certain a character survived.

That problem is gone. HTML5 defaults to UTF-8, every browser in use supports it, and a correct <meta charset="utf-8"> makes the whole exercise unnecessary. What remains is cost: output several times larger for non-Latin text, content that no longer matches when searched, and diffs that are unreadable.

There are still legitimate uses, and they are narrow: a downstream system that mangles UTF-8 and cannot be fixed, an email client with a hostile transfer encoding, or a template pipeline that transcodes to ASCII somewhere you do not control. If none of those apply — and they usually do not — leave the option off. Escaping é does not make a page safer; only the five special characters affect parsing.

Escaping is context-sensitive, and this covers one context

HTML escaping is the correct defence for text placed in element content or in a quoted attribute value. It is not sufficient everywhere, and knowing the boundary matters:

• Inside a <script> block, HTML entities are not decoded. Injecting escaped text into JavaScript source does nothing to protect you — that context needs JSON encoding or JavaScript string escaping.
• Inside a URL attribute such as href or src, escaping does not stop a javascript: scheme. Validate the scheme, and percent-encode the value.
• Inside a style attribute or a CSS block, CSS has its own escaping rules; HTML entities do not apply.
• Unquoted attributes can be broken out of with a space alone. Always quote your attributes; then escaping quotes is enough.

One more practical warning: escape once, at the point of output. Escaping on input and again on output gives you < rendering as a visible <, the double-escaping bug that shows up in comment threads and support tickets everywhere. And in application code, prefer your template engine's automatic escaping over doing it by hand — this tool is for the cases where you are producing static markup, preparing a code sample, or debugging exactly what a system escaped.