HTML Entity Encoder
Note: Escaping is context-dependent, and this is the HTML-body form. It is not sufficient inside an unquoted attribute, inside a script tag, or in a URL — and client-side encoding is never a security control. Escape where the output is assembled, on the server.
The order of the replacements matters and is a classic bug. The ampersand has to be encoded first, because if you encode the angle brackets first you produce ampersands that the ampersand rule then encodes again, and < becomes < — the double-encoding that shows literal entity text on the page. This tool always encodes the ampersand first.
A word on what this is not. Escaping is context-dependent: HTML body, HTML attribute, JavaScript string and URL each need different treatment, and applying the wrong one is not safe. The four-character escape is correct for body text and for a properly quoted attribute. It is not sufficient inside an unquoted attribute, inside a script tag, or in a URL parameter. Client-side encoding is also not a security control — anything protecting against injection has to happen where the output is assembled, on the server.
The named and numeric forms are equivalent. Numeric works everywhere including XML; named is more readable but only a defined set exists, so numeric is the safer default for anything machine-generated.
Frequently Asked Questions
Which characters actually need encoding?
In body text, just & < and >. Inside an attribute, also the quote character you are using. Everything else is optional on a UTF-8 page — encoding accented letters or curly quotes makes the source harder to read and the file larger for no benefit.
Why do I see < on my page?
Double encoding — the text was escaped twice, or the angle brackets were escaped before the ampersand so the resulting entities got escaped again. Always encode the ampersand first, and check the value is not already escaped before escaping it.
Does this protect against XSS?
No. It is a text conversion running in your browser, and escaping has to happen where the output is built, on the server, using the escaping appropriate to that context. HTML body, attributes, JavaScript strings and URLs all need different treatment.
Named or numeric entities?
They render identically. Numeric works everywhere including XML and needs no lookup table, which makes it the safer default for generated output. Named entities are easier for a human to read, but only a defined set exists — there is no named entity for most characters.
Should I encode non-ASCII characters?
Not on a UTF-8 page, which is every page you should be serving. It was necessary in the Latin-1 era and is now just noise. If a character is arriving mangled, the fix is the charset declaration, not entity encoding.
