HTML Encoder

About the HTML Encoder

Characters that carry special meaning in HTML, &, <, >, " and ', get swapped for their named entity equivalents so the result can be dropped safely into markup or an attribute without breaking the page.

Turn on "Encode all non-ASCII characters" if you also need accented letters, emoji, and anything past code point 127 converted into numeric entities like é, handy for older systems that expect strict ASCII output.

Why the ampersand is replaced first, and why that order matters

The encoder runs five sequential .replace() calls, and the very first one turns every literal & into &. That ordering isn't arbitrary — since every entity this tool inserts (<, >, ", ') itself contains an ampersand character, encoding & anywhere but first would re-encode the entities the tool had just inserted a moment earlier, turning < into the broken double-encoded <. Doing the ampersand pass before any other character avoids that entirely, which is the same rule any correct manual HTML-escaping implementation has to follow.

The apostrophe uses a numeric entity, not '

Single quotes are encoded as ' rather than the more readable named entity '. This is deliberate: ' is valid in XML and HTML5, but it was never part of the original HTML 4 named-entity table, so older parsers, some XML-unaware HTML processors, and a handful of legacy tools don't recognize it. The numeric form ' resolves to the same apostrophe character in every HTML version back to HTML 2, so it's the safer default when you don't control what will eventually parse the output.

Non-ASCII encoding handles emoji correctly, not just accented letters

When "Encode all non-ASCII characters" is on, the tool doesn't loop over the string by index — it uses Array.from(text), which iterates by full Unicode code point rather than by raw UTF-16 code unit. That distinction matters for anything outside the Basic Multilingual Plane, like most emoji: a naive for loop over string indices would split a four-byte emoji into its two orphaned surrogate halves and encode each one separately, producing two broken, meaningless numeric entities where one correct one was needed. Iterating by code point instead means an emoji like 🎉 is read as a single unit and encoded as one valid decimal entity, 🎉, that decodes back to the exact same character.

This covers the same character set security libraries treat as unsafe

The five characters this tool escapes by default, &, <, >, ", and ', are the same minimal set most HTML-context output-encoding libraries (including the ones referenced in OWASP's XSS prevention guidance) treat as the baseline that must be escaped before untrusted text is inserted into an HTML page or attribute. Encoding just these five is enough to stop a string like <script>alert(1)</script> from being interpreted as executable markup if it were pasted into a page as plain text content — though this tool doesn't attempt to sanitize or block anything, it only performs the character substitution, so it's on you to actually use the encoded output in place of the raw text.

Both quote characters are escaped, even though only one is usually needed

Both the double quote and the single quote get replaced regardless of which one your target markup actually uses to delimit an attribute value. This is a deliberate over-encode: since the result might end up inside attr="value" or attr='value' depending on how the destination markup is written, and the tool has no way of knowing which quote style will wrap the output, escaping both removes the ambiguity rather than making you specify a quoting context up front. The tradeoff is a slightly more escaped-looking result than strictly necessary for plain text content between tags, where neither quote character is actually dangerous — but for attribute-safe output, escaping both is the only choice that's correct in every case.