<, &, ', and " back into the original characters (<, &, ', "). The encoder does the reverse — replacing unsafe HTML characters with named or numeric entities so the browser renders them as text instead of parsing them as markup. Use our free HTML encoder/decoder to escape user input safely or recover content from a feed that arrived double-encoded.Every web developer eventually pastes a string from a CMS export, an XML feed, or a database column and sees &quot;Hello&quot; where they expected "Hello". That’s an HTML entity round-trip gone wrong. HTML escapes a small set of characters that have structural meaning — <, >, &, ", ' — into named entities (<, >, &, ", ') so they appear as text rather than triggering tag parsing. Get the encoding right and your user-supplied content is rendered safely; get it wrong and you have either visible escape sequences or, worse, an XSS vulnerability.
Our HTML encoder and decoder handles named entities (é, ©, –), numeric decimal entities (é, ©), numeric hex entities (é), and the full HTML5 named-entity table (2,231 named entities). It runs entirely in your browser. This guide covers when to encode, the difference between named and numeric entities, double-encoding, and the XSS edge cases naive encoders miss.
The 5 characters you must always escape — and 2 you should
| Character | Named entity | Numeric (decimal) | Required in |
|---|---|---|---|
& |
& |
& |
Everywhere — encode first or you’ll double-encode |
< |
< |
< |
Text content — prevents tag injection |
> |
> |
> |
Text content (defensive — not strictly required) |
" |
" |
" |
Inside double-quoted attributes |
' |
' |
' |
Inside single-quoted attributes (note: ' is HTML5 only) |
© |
© |
© |
Optional — only if not serving as UTF-8 |
— (em dash) |
— |
— |
Optional — only if not serving as UTF-8 |
Named vs numeric vs hex entities
You’ll see HTML entities in three forms in the wild. Named entities like © are readable but only work for the ~2,231 characters that have an HTML5 name. Numeric decimal entities like © reference the Unicode code point in base 10. Hex entities like © reference the same code point in base 16. All three render identically.
- Use named when readability matters and the character has a well-known name (
,©,™). - Use numeric when you want maximum compatibility — every Unicode code point can be expressed numerically; not every character has a named entity.
- Use hex when copying from a Unicode reference where code points are listed in hex (
U+00A9→©). Hex is also more compact for high-codepoint characters.
Important: ' for the single quote is HTML5-only. In HTML4 and XHTML 1.0 it’s not in the named-entity table — emails and old browsers may render it literally as '. Use ' for maximum compatibility, especially in HTML emails.
How to encode or decode HTML in your browser
- Open the HTML encoder/decoder
- Paste the string in the input box
- Pick Encode (text → entities) or Decode (entities → text)
- For encode, optionally toggle Numeric only to skip named entities (safer for emails and legacy clients)
- Click Copy to copy the output, or Decode again if the result still contains entity sequences (double-encoded data)
XSS-safe context-aware encoding (what naive encoders miss)
HTML entity encoding is not a one-size-fits-all defence against XSS. The right escape depends on where in the page you’re inserting user data. The OWASP-recommended split:
- HTML body context: escape
<,>,&. Inserting user text between tags. - HTML attribute context: additionally escape
"(or'if your attribute uses single quotes). Always quote your attributes; unquoted attributes are an injection vector. - JavaScript context: HTML entity escaping does not protect you here. Use JavaScript string escaping (
<for<) or, better,JSON.stringify. - CSS context: use CSS hex escapes (
\3Cfor<), not HTML entities. - URL context: use URL encoding (
%3Cfor<), not HTML entities.
Our encoder produces HTML-context escapes by default with an option for attribute-context (more aggressive). For JavaScript or URL contexts, use the URL encoder or escape inside JSON.
Common gotchas
- Encode the ampersand first. If you encode
<to<first, then encode&to&, you’ll double-encode and end up with&lt;. Always replace&first, then the rest. - Double-encoded feeds. RSS feeds, MailChimp exports, and CMS APIs sometimes encode their own escape sequences again.
&amp;means the original was&encoded twice. Decode twice to recover. - Non-breaking space looks like a space but isn’t.
(U+00A0) is invisible but breaks string-equality checks. If your string compare fails despite identical-looking text, replace nbsp with regular space first. - Internet Explorer recognised non-standard named entities. Avoid
'in HTML emails for IE/Outlook compatibility — use'. - Numeric entities work for any code point. Need a thumbs-up emoji?
👍works everywhere; the named entity does not exist. - UTF-8 makes most named entities unnecessary. If your page is served as
charset=utf-8(which it should be in 2026), you only need to escape&,<,>,", and'. Don’t encode©,—,é— just write them directly.
When NOT to use this tool
For server-side templating, use your framework’s auto-escaping: React ({value} escapes by default), Vue, Handlebars, Jinja2, Thymeleaf, ERB, Liquid all escape HTML automatically. Only reach for an external encoder when you have a stuck string from a feed, log, or copy-paste of an export. For programmatic encoding in client-side JS, element.textContent = userInput is safer than building an HTML string and encoding it — the DOM API never confuses content with markup.
Frequently asked questions
What’s the difference between HTML entity encoding and URL encoding?
Different places, different rules. HTML entity encoding makes characters safe to include inside an HTML document (& → &). URL encoding (percent-encoding) makes characters safe to put inside a URL (& → %26). They are not interchangeable. Use HTML for HTML, URL for URLs.
Why does my page show &quot; instead of “?
Double-encoding. The string was encoded once (" → "), then encoded again, so & became & and the result is &quot;. Decode twice to recover. Long-term fix: encode at exactly one layer of your stack — typically right before output, never during storage.
Does my framework already escape HTML?
Probably yes, if you use template syntax like React’s {value}, Vue’s {{ value }}, Jinja2’s {{ value }}, or Handlebars’s {{ value }}. All escape by default. The dangerous variants — React’s dangerouslySetInnerHTML, Vue’s v-html, Jinja2’s |safe — bypass escaping. Audit those carefully.
Should I use named or numeric entities?
Numeric is more universal. Named entities (©) are readable but only ~2,231 characters have HTML5 names. Numeric entities (©) work for every Unicode code point. For HTML emails, prefer numeric — old email clients may not recognise newer named entities like '.
Is my data uploaded?
No. The encoder/decoder runs in your browser via JavaScript. Pasted content is never sent to our servers, which makes it safe for decoding tokens, signed cookies, or potentially sensitive feed data.
How many named HTML entities exist?
HTML5 defines 2,231 named character references. They cover the named entities from HTML4 plus many more — including math symbols, arrows, and Greek letters. Our decoder handles all of them. The full list is in the WHATWG HTML spec.
Related tools and guides
