About the HTML Encode
Five characters decide whether a browser reads your content as text or as instructions. An unescaped < starts a tag, an unescaped & starts an entity, and a stray quote inside an attribute ends it early and lets whatever follows become new attributes. Encoding those five is how user supplied content stops being a cross site scripting vector.
The default setting encodes exactly that set: ampersand, less than, greater than, double quote and apostrophe, in that order so the ampersands introduced by the escaping are not escaped twice. The wider setting also converts every character above the ASCII range, which is what you need for a document served without a declared UTF-8 charset, or for a legacy system that only accepts seven bit content.
Three entity styles are available. Named entities such as é and € read well in source but only exist for a fixed list. Decimal numeric entities work for every code point including emoji. Hexadecimal numeric entities are the style used in most specifications and in XML tooling.
A caveat worth remembering: entities are not a substitute for context aware escaping. Text placed inside a script block, a style block or a URL attribute needs the rules of that context, not these. Reverse the operation with HTML Decode.
How to use
- Paste the text or markup you want to neutralise.
- Leave Markup characters only selected for normal page content, or choose the wider option for legacy targets.
- Pick an entity style, then copy the encoded text into your template.
Common questions
- Which characters does the default setting encode?
- Ampersand, less than, greater than, double quote and apostrophe. Those five cover every way text can escape into markup.
- Named or numeric entities?
- Named entities are easier to read but limited to a fixed list. Numeric entities cover every code point, so use them for unusual symbols.
- Do I still need this on a UTF-8 page?
- For the five markup characters, always. Encoding accents and symbols is optional once the page declares UTF-8.
- Does this make user input safe everywhere?
- No. Content inside a script tag, a style block or a URL attribute needs escaping rules specific to that context.