HTML Entity Encoder / Decoder

Turn special characters into HTML entities — & for ampersands, © for ©, numeric codes for everything else — or decode entity-filled text back into readable characters. Handles named, decimal, and hexadecimal entities, live as you type, entirely in your browser.

Plain Text

Encoded

Named entities where common, numeric (&#…;) otherwise. Decode handles named, decimal, and hex entities.

How to Use HTML Entity Encoder / Decoder

1

Choose Encode or Decode

Pick Encode to convert special characters into entities, or Decode to turn entities back into readable characters.

2

Paste your text

Enter text in the left panel — the converted version appears live on the right. Toggle 'Encode all non-ASCII' if you need pure-ASCII output.

3

Copy the result

Click Copy Output to grab the converted text for your HTML, template, or email.

About HTML Entity Encoder / Decoder

Why HTML needs entities

Five characters have structural meaning in HTML: < and > delimit tags, & starts entities, and quotes delimit attribute values. Put them in your content raw and the browser misinterprets them — a stray < can swallow the rest of your paragraph as a malformed tag. Entities solve this by representing characters as safe sequences: &lt; renders as <, &amp; as &. Entities also let you express characters that are hard to type or that might not survive a file's character encoding, like ©, é, em dashes, and arrows.

Named, decimal, and hex forms

Every character can be written as a numeric entity using its Unicode code point — &#169; in decimal or &#xA9; in hex both mean ©. Common characters also have memorable named entities like &copy;, &nbsp;, &mdash;, and &euro;, which make source code far more readable. This tool encodes with names where a well-known one exists and falls back to numeric form otherwise, and the decoder accepts all three formats interchangeably — so it handles whatever mix appears in the HTML you're cleaning up.

Encoding and escaping safely

Encoding entities is also a security practice: escaping user-supplied text before inserting it into HTML is the fundamental defense against cross-site scripting, because &lt;script&gt; displays as text instead of executing. This tool always encodes the five HTML-significant characters, and the encode-all-non-ASCII option additionally converts every character above the ASCII range — useful when your pipeline can't guarantee UTF-8 survives intact. Both directions run entirely in your browser with nothing uploaded, and decoding uses the browser's own parser in a way that never executes the input.

Common uses for HTML Entity Encoder / Decoder

  • Escape code snippets so they display correctly in blog posts and docs
  • Encode user-generated text before inserting it into HTML templates
  • Decode entity-filled text scraped from web pages or email source
  • Fix double-encoded content showing &amp;amp; instead of &
  • Prepare special characters like © and — for maximum email client compatibility

Frequently Asked Questions

When do I actually need to encode entities?

Encode whenever text becomes part of HTML markup: displaying user input, showing code examples on a page, or putting dynamic values into attributes. The critical characters are & < > and quotes. You don't need to encode accented characters if your page declares UTF-8 — but encoding them is a safe fallback when you can't control the encoding downstream, like in some email clients.

What's the difference between &#169; and &#xA9;?

They're the same character — © — written in decimal and hexadecimal. The x after &# signals hex notation. Browsers treat them identically, and this tool decodes both. When encoding, it prefers the named form &copy; where one exists, since names are self-documenting, and uses decimal numeric entities for characters without a common name.

Why does &apos; sometimes cause problems?

&apos; was defined in XML but not in HTML4, so some older parsers and email renderers don't recognize it. The numeric form &#39; means the same apostrophe and works everywhere, which is why this tool uses it when encoding. When decoding, &apos; is understood fine — the asymmetry exists purely for maximum compatibility of your output.

Does the encode-all-non-ASCII option change what readers see?

No — &eacute; and a literal é render identically. The option only changes the source representation. Turn it on when your HTML passes through systems that might mangle UTF-8, such as legacy email pipelines or misconfigured servers, since ASCII-only source survives any encoding confusion. Leave it off for smaller files and more readable source.

Is decoding untrusted HTML here safe?

Yes. Decoding uses your browser's DOMParser to interpret entities without ever attaching the input to the live page, so scripts and event handlers in the text cannot execute. And since everything runs client-side, the content itself never leaves your machine — you can safely decode scraped HTML, email source, or database exports containing anything.