HTML Entity Encoder & Decoder — Escape or Unescape HTML
Turn < & " into safe entities, or decode any entity the browser knows — named, decimal or hex.
🔒 Runs in your browser — files never uploaded ⚡ No signup 💯 Free
Encode text so it displays literally inside HTML — < becomes <, & becomes & — or decode a string full of entities back into readable characters. Encoding offers named entities (é), decimal (é) or hex (é), and lets you choose between escaping only the dangerous five or every non-ASCII character.
Decoding uses the browser's own HTML parser, so all 2,231 HTML5 named entities are recognised — not just the common few — including legacy forms without a trailing semicolon.
How to use HTML Entity Encoder / Decoder
- Pick Encode or Decode.
- Paste your text. The result updates as you type.
- For encoding, choose what to escape (just
& < > " ', or every non-ASCII character too) and the entity style. - Copy the output, or Swap to feed it back in and confirm it round-trips.
What entities are for
HTML has five characters with syntactic meaning: < and > delimit tags, & starts an entity, and " and ' close attribute values. To show any of them as text, you write an entity instead. Every other character can appear literally in a UTF-8 page — entities for accented letters and symbols are a leftover from the days of Latin-1 encodings, useful now mainly when a system mangles non-ASCII, or when you want the source to be readable in plain ASCII.
Encoding is the XSS defence — with a caveat
Putting user input into a page without escaping these five characters is cross-site scripting: <script> in a comment becomes a running script for every reader. Escaping them is the fix for HTML text and attribute contexts. It is not the fix for a URL (percent-encode), a JavaScript string (JSON-encode), or CSS. Use the encoder that matches where the text is going; for URLs, that's the URL encoder.
Named, decimal or hex?
- Named (
©,—) — readable in source. All 252 HTML4 names work in every browser; HTML5 added ~2,000 more that older email clients may not know. - Decimal (
©) — universally supported, including XML and every email client. - Hex (
©) — same support as decimal, and matches Unicode code-point notation (U+00A9), which makes it easier to look up.
This tool writes the apostrophe as ' rather than ': ' comes from XML and was only added to HTML in HTML5, so some older parsers show it literally.
Decoding safely
Decoding happens inside a <textarea>, whose content the parser treats as raw text: entities are resolved but tags are not — nothing can execute, however hostile the input. Decoded output is text; if you place it back into a page, encode it again.
Frequently asked questions
Which characters must I encode in HTML?
Five: & → &, < → <, > → >, and inside attributes " → " and ' → '. Everything else can appear literally in a UTF-8 page. The default "essential" mode encodes exactly these.
Should I use &nbsp; and &eacute; or the real characters?
Real characters, in almost every modern context — the page is UTF-8 and they render fine. Named entities remain useful when a pipeline strips or mangles non-ASCII (some email systems, old CMSes), or when makes an intentional non-breaking space visible in source.
Why &#39; instead of &apos;?
' was defined for XML and only became valid HTML in HTML5. Older HTML parsers and some email clients display it literally as text. ' is understood by everything, so it is the safe choice.
Is decoding untrusted input here dangerous?
No. Decoding is done inside a textarea, where the browser resolves entities but never interprets tags — <script> becomes the text <script> and nothing runs. Just remember the decoded text is unsafe to paste back into a page without encoding it again.
Does this also encode for URLs or JavaScript?
No — each context has its own escaping and using the wrong one is a classic bug. URLs need percent-encoding (URL encoder); JavaScript strings need JSON/backslash escaping. HTML entities are only for text and attribute values in HTML.