HTML Entity Encoder / Decoder
Escape text for safe HTML, or decode entities back to readable characters.
Escaping &, <, > and quotes is what stops user-supplied text being read as markup — the root cause of most cross-site scripting bugs. Decoding is deliberately limited to numeric references and common named entities.
Escape special characters in text into their safe HTML entity form (like & for &, or < for <), or decode existing entities back into readable characters — necessary whenever text containing HTML-significant characters needs to be embedded safely in a web page.
Skipping this step is a classic source of broken page rendering, or in the worst case, a cross-site scripting vulnerability when untrusted text is embedded raw.
The five characters that always need escaping
| Character | Named entity | Numeric | Why |
|---|---|---|---|
| & | & | & | Starts every entity — escape it first |
| < | < | < | Opens a tag |
| > | > | > | Closes a tag |
| " | " | " | Ends a double-quoted attribute |
| ' | ' | ' | Ends a single-quoted attribute |
Order matters when escaping by hand: escape & first, or you'll double-escape the ampersands you just introduced.
Escaping is context-dependent
HTML entity encoding is correct for text inside an element or an attribute value. It is not correct everywhere, and applying the wrong escaping is a security bug rather than a cosmetic one.
Text inside a <script> block needs JavaScript string escaping. A value inside a URL needs percent-encoding. A value inside a CSS declaration needs CSS escaping. Each context has its own parser and its own escape sequences, which is why modern frameworks escape automatically per context rather than leaving it to the developer.
- Prefer your framework's automatic escaping to manual encoding — React, Vue, Angular and modern template engines all escape by default.
- Anything that bypasses it (dangerouslySetInnerHTML, v-html, innerHTML) is where XSS bugs live. Sanitise with a library rather than a regex.
- Escape at the point of output, not on input. Escaping on the way into the database corrupts the data for every other consumer.
Frequently asked questions
- Why do I need to encode characters like < and & for HTML?
- Those characters have special meaning in HTML markup — an un-escaped < can be interpreted as the start of a tag. Encoding them as entities ensures they display as literal text instead.
- What's the difference between named and numeric entities?
- Named entities (&) are more readable; numeric entities (&) work even for characters without a common name and are guaranteed to be understood by any HTML parser.
- Is entity encoding the same as URL encoding?
- No — they solve different problems. HTML entity encoding protects characters inside HTML markup; URL encoding (percent-encoding) protects characters inside a URL. Use the matching tool for the context you're in.
- Does escaping HTML protect me from XSS?
- In the right context, yes — but escaping is context-specific. HTML escaping doesn't protect a value inserted into a script block, a URL, or a CSS rule. Use your framework's context-aware escaping rather than one blanket encode.
- Should I escape text before storing it in the database?
- No. Store the raw text and escape when rendering. Escaping on input corrupts the data for any consumer that isn't HTML — an API, a CSV export, a mobile app.