HTML Entity Encoder
Convert characters to HTML entities and back for safe embedding in markup.
How to use the HTML Entity Encoder
Choose Encode or Decode.
Paste your HTML snippet or entity-encoded text.
Copy the safe output for embedding in markup, or the decoded text for reading.
What is HTML entity encoding, and why does it matter for security?
Browsers treat <, >, and & as markup control characters — type <script> into a page without escaping it and the browser tries to run it as an element, not display it as text. HTML entities sidestep this by representing those characters as text sequences instead: & becomes &, < becomes <, > becomes >, and quotes become " / '. Entities come in two flavors — named (&, ©) and numeric, which can be decimal (&) or hexadecimal (&) — all three decode to the same character, and this tool reads either. The security angle: encoding untrusted user input before inserting it into an HTML page is one half of XSS prevention (the other half is picking the right encoding for the context — HTML entities protect HTML text nodes, but attribute values, URLs, and JavaScript contexts need their own escaping rules, which is why frameworks like React auto-escape by default rather than relying on manual entity encoding everywhere).
For a step-by-step walkthrough, read our guide: HTML Entity Encoding: Prevent XSS and Display Special Characters.
Key features
- Encode the five reserved characters (& < > " ') to named entities
- Decode both named (&) and numeric (& / &) entities back to text
- Safe way to display raw HTML/code samples on a page without them rendering as markup
- Runs locally — no code sample or markup ever leaves your browser
Frequently asked questions
Which characters actually get encoded?
The five HTML-reserved characters: & < > " and ' — that's the minimum set needed to safely place arbitrary text inside an HTML text node or a quoted attribute.
Does entity-encoding alone prevent XSS?
It prevents the HTML-text-node case, but XSS defense is context-dependent — untrusted data inside a <script> block, a URL, or an unquoted attribute needs different escaping, so entity-encoding should be one layer of a broader output-encoding strategy, not the only one.
Can it decode numeric entities like & or &?
Yes — decimal (&), hexadecimal (&), and named (&) entities all decode to the same character; this tool handles all three forms.
Why would I want to encode instead of just using a <pre> tag?
A <pre> tag preserves whitespace but doesn't stop < and & inside it from being parsed as markup — you still need entity encoding to show a literal <div> or A && B as visible text.