HTML Entity Encoder / Decoder
Encode and decode HTML entities with a full reference table, plus why entity encoding alone is not safe inside script blocks, URLs or CSS.
Result
What HTML Entity Encoder / Decoder Does
HTML entities let you write characters that would otherwise be interpreted as markup, or that are hard to type. There are three forms: named (&), decimal (&) and hexadecimal (&). All three produce the same character.
Only five characters strictly need escaping in HTML, and which of the five depends on where the text appears. Inside ordinary text you need to handle & and <. Inside an attribute value you also need the quote character that delimits it.
The important thing this tool cannot do for you is choose the right encoding for the context. HTML entity encoding is the correct defense when text lands in HTML body content. When the same text lands inside a script block, a URL, or a CSS value, it is not sufficient and can be actively useless.
How to Use HTML Entity Encoder / Decoder
- Select Encode or Decode mode
- Paste your raw text or HTML code into the input area
- View the converted safe HTML entity string and click Copy Result
How HTML Entity Encoder / Decoder Works
Encoding to numeric character references
each of < > & " ' and every character from U+00A0 upward → &#decimal-code-point;
- &#N;
- A decimal numeric character reference. HTML parsers turn it back into the character whose Unicode code point is N, so it works for any character, including ones with no named entity.
- code point
- The character's Unicode number, read with codePointAt so that an emoji (two UTF-16 code units) becomes one reference, not two broken halves.
- Decode mode
- The text is parsed by the browser's own HTML parser (through a textarea element), so named (&), decimal (&) and hexadecimal (&) references are all understood exactly as a page would read them.
Worked example
Encode: <p>Café & "Tea" 🚀</p>
- < is U+003C → < and > is U+003E → >
- é is U+00E9 → é and & is U+0026 → &
- Each " is U+0022 → "
- 🚀 is U+1F680 → 🚀
- Plain ASCII letters and spaces are left as they are
Result: <p>Café & "Tea" 🚀</p>, which a browser displays as the original text rather than rendering a paragraph.
The Characters That Must Be Escaped
Verified against actual Unicode code points.
| Character | Named | Decimal | Escape when |
|---|---|---|---|
| & | & | & | Always — and always first |
| < | < | < | Always in body text |
| > | > | > | Recommended, not strictly required |
| " | " | " | Inside double-quoted attribute values |
| ' | ' | ' | Inside single-quoted attribute values |
Entities People Actually Look Up
Including the two that get asked about most often.
| Character | Named | Decimal | Name |
|---|---|---|---|
| • | • | • | Bullet — the • in the PAA question |
| ' | ' | ' | Apostrophe — the ' in the PAA question |
| |   | Non-breaking space | |
| © | © | © | Copyright |
| ® | ® | ® | Registered trademark |
| ™ | ™ | ™ | Trademark |
| — | — | — | Em dash |
| – | – | – | En dash |
| € | € | € | Euro |
| ½ | ½ | ½ | One half |
Encoding Depends on Context
The single most important thing about output encoding, and the thing simple encoders never mention. HTML-encoding text that lands in a script block does not make it safe.
| Where the text lands | Correct encoding | HTML entities sufficient? |
|---|---|---|
| HTML body text | HTML entity encoding | Yes |
| HTML attribute value | HTML entity encoding, and always quote the attribute | Yes, if quoted |
| Inside a <script> block | JavaScript string escaping, or JSON serialization | No |
| A URL or query parameter | Percent-encoding | No |
| A CSS value | CSS escaping | No |
| An unquoted attribute | Nothing is safe — quote the attribute | No |
How to Read Your Result
Escape the ampersand first
Order matters, and people get it wrong constantly. If you replace < with < before replacing & with &, the ampersand you just introduced gets escaped again and "<a>" becomes "&lt;a>", which is visible corruption. Verified: escaping & first gives the correct "<a>". Always handle & before anything else.
Entity encoding is not XSS protection on its own
It is the right defense in exactly one context: HTML body text. Text inserted into a script block, a URL, an event handler attribute or a CSS value needs that context's own escaping. A value that is HTML-encoded and then written into an href can still execute a javascript: URL. Match the encoding to the destination.
Named entities are limited; numeric ones are not
HTML defines a fixed list of named entities. Anything outside it, which is most of Unicode, must use the numeric form. 😀 and 😀 both produce an emoji; there is no named entity for it. If you are unsure whether a name exists, the numeric form always works.
Non-breaking space is not a layout tool
prevents a line break and prevents whitespace collapsing, which makes it useful for keeping "10 kg" together. Using strings of them for indentation or spacing is fragile and inaccessible: screen readers may announce them, and the layout breaks at other viewport widths. Use CSS.
Limitations & Accuracy Notes
- Encoding and decoding run in your browser; nothing is transmitted.
- This encodes for HTML contexts. It does not perform JavaScript, URL or CSS escaping, and using its output in those contexts is not safe.
- Decoding accepts named, decimal and hexadecimal references. Malformed references are left as literal text rather than guessed at.
- It does not sanitize HTML. Encoding makes markup display as text; it does not strip dangerous elements from markup you intend to render. Those are different jobs and need a sanitizer.
- Whether > must be escaped is a common argument. The HTML specification only requires it in limited cases, but escaping it is harmless and avoids the question.
- Encode mode uses decimal references for everything it changes, including characters that have a familiar named entity (& becomes &, not &). Both are equally valid HTML.
Frequently Asked Questions
Why do developers encode HTML entities?
HTML entity encoding replaces reserved HTML characters (<, >, &, ", ') with entity representations to prevent browser injection and cross-site scripting (XSS).
What is the HTML entity for an ampersand and quotes?
An ampersand is & (&), a double quote is " ("), and a single apostrophe is '.
What is the difference between named and numeric HTML entities?
Named entities like & are easier to read and defined for common characters. Numeric entities work for any Unicode character, including ones without a defined name, using decimal or hex code points.
Does encoding entities prevent all XSS attacks?
No. Entity encoding for HTML output is one important layer, but full XSS prevention also requires proper encoding for JavaScript, URL, and CSS contexts, plus a Content Security Policy.
Which characters must be escaped in HTML?
At minimum the ampersand, less-than and greater-than signs. Inside an attribute value, quotes must be escaped too: " for double and ' for single. Escaping the ampersand first matters, because escaping it after the others would double-escape them.
Does escaping prevent XSS?
Context-appropriate escaping is the core defense, but the correct escaping depends on where the value lands. HTML-escaping a value that is inserted into a JavaScript string, a URL or a CSS rule does not make it safe. Each context has its own rules, and a value placed inside a script tag needs a different treatment entirely.
What is the difference between a named and a numeric entity?
Named entities such as & are readable; numeric ones such as & or & refer to the Unicode code point directly. Numeric entities always work, whereas named ones are limited to a defined list, so anything unusual has to be numeric.
Do I need to escape accented or non-Latin characters?
Not if the page is served as UTF-8, which it should be; modern browsers render them directly. Escaping them is legacy practice from an era of uncertain encodings and mostly makes the source harder to read.
What is a non-breaking space?
renders as a space that will not collapse with adjacent whitespace and will not be used as a line-break point. It is useful for keeping a number and its unit together, and it is frequently pasted invisibly from word processors, where it causes layout problems that are very hard to see.
Is my input sent to a server?
No. Encoding and decoding both run in your browser.
References & Further Reading
- WHATWG HTML Standard — Named character references — The complete authoritative list of named entities
- OWASP — Cross Site Scripting Prevention Cheat Sheet — Why output encoding must match the context it lands in