HTML Entity Encoder/Decoder converts characters that are meaningful to HTML, such as <, >, & and quotes, into their entity form (<, &, or a numeric reference), and decodes entities back to plain text.
How to read the result
The output shows the converted string. Encoding converts the five characters that matter in HTML (&, <, >, " and '), and you can choose named entities (&) or numeric references (&), which any browser treats the same. Decoding understands both forms and never runs or loads anything you paste.
Defender tips
- Entity-encoding output is one layer of cross-site scripting defence, but it must match the context: encoding for an HTML body is not enough for an attribute, a
<script>block or a URL; each context needs its own escaping rules. - Prefer a templating engine or framework that auto-escapes by default over hand-rolled encoding calls scattered through the codebase; a single place you forgot is all it takes.
- Do not rely on encoding alone as your only XSS control; pair it with a Content-Security-Policy so a missed encoding call is not the only thing standing between input and execution.
FAQ
What is the difference between named and numeric entities?
Both render identically in a browser; named entities (<) are more readable to a person, numeric references (<) are useful when a named entity is not defined for the character you need.
Why are some characters left unchanged?
Only the five characters with special meaning in HTML are converted. Letters, digits, other punctuation and characters outside ASCII pass through unchanged, which is safe in a UTF-8 page.
Does entity-encoding fully prevent XSS?
On its own, no. It prevents a specific class of injection into HTML body content; script contexts, attributes and URLs each need their own escaping, which is why a security review checks context, not just presence of encoding.