HTML Entity Encoder / Decoder

Encode escapes the five characters that break or subvert HTML - &, <, >, ", and ' - making arbitrary text safe to drop into element content or attribute values. Decode goes the other way and understands the full range: named entities (é), decimal (é), and hex (é) references all come back as real characters, because decoding uses the browser's own HTML parser rather than a lookup table that covers thirty entities and shrugs at the rest.

How to use the HTML entity encoder and decoder

1. Paste your text into the Input box. For encoding, that is the raw text you want to show on a web page. For decoding, it is text full of sequences like & or é.
2. Click Encode entities to escape the text for HTML, or Decode entities to turn entity references back into characters.
3. Read the result in the Output box. Nothing is rendered, so tags in the output are shown as text, not applied.
4. Click Copy result to copy it, or Clear to empty both boxes.

How character references work

HTML reserves a few characters for its own syntax. < opens a tag, & starts a character reference, and quotes delimit attribute values. To show one of those characters as text, you write a reference instead, and the browser replaces it when it renders the page. References come in three forms, all of which mean the same é:

• Named: é, a name from the list defined in the HTML standard.
• Decimal: é, the Unicode code point in base 10.
• Hexadecimal: é, the same code point in base 16.

The encoder replaces the ampersand first, then the other four characters. The order matters. If < were replaced first, the ampersand in the new < would get escaped a second time. Because the ampersand goes first, running the encoder once always produces exactly one layer of escaping.

The decoder uses the browser's own HTML parser, so it also follows the parser's older compatibility rules. Some of them surprise people:

• Some older names, such as &copy, &amp, and &not, still work without the closing semicolon. &copy 2026 decodes to © 2026.
• Numeric references in the range 128 to 159 are read as Windows-1252 characters, because old pages used them that way. – becomes an en dash (U+2013) instead of an invisible control character.
• � and references to surrogate code points become the replacement character �.
• Unknown names such as &unknown; and bare ampersands such as AT&T are left exactly as they are.

A worked example

Suppose you want to show this link as code on a web page, not as a working link:

<a href="/search?q=tom&jerry" title='Tom's'>Tom & Jerry</a>

Click Encode entities and the output is:

<a href="/search?q=tom&jerry" title='Tom's'>Tom & Jerry</a>

Both ampersands, all four angle brackets, both double quotes, and all three apostrophes were replaced. Pasted into a page, it displays as the original line of code.

Going the other way, decode this:

Café & crème → &copy 2026

The output is:

Café & crème → © 2026

Named, decimal, and hex references all resolved, and &copy worked without its semicolon. The gap before the arrow looks like a normal space but is a non-breaking space, U+00A0.

Common problems and how to fix them

The page shows & or <

The text was escaped twice, often once by your code and again by a template engine that escapes automatically. Decoding removes exactly one layer per click, so < decodes to <. Find the step that escapes a second time and remove it rather than decoding at display time.

A URL's query string got mangled when decoding

Query strings contain ampersands followed by parameter names, and some names match legacy entities. ?page=2&copy=true&lang=en decodes to ?page=2©=true&lang=en. Only decode text that is actually HTML-escaped. If you are cleaning up a URL, use a URL decoder instead.

Search or comparison fails on decoded text

If the source used  , the decoded text contains non-breaking spaces. They look identical to spaces but do not match a space in code, spreadsheets, or a find box. Replace U+00A0 with a regular space after decoding when you need plain text.

Decoding did not remove the tags

Decoding only converts entity references. Literal tags like <b> in the input stay in the output as text. To get plain text from HTML markup, strip the tags separately.

Line endings changed

Decoding normalizes Windows line endings, so CRLF pairs in the input come out as single line feeds. This rarely matters, but it shows up as a whole-file change in a strict diff.

Related tasks

Text headed for a link or query parameter needs the URL encoder rather than HTML escaping. To check your work, the text diff checker shows exactly what an encode or decode pass changed.

Questions this tool gets asked

Which characters does encoding escape?

The five with special meaning in HTML: ampersand, less-than, greater-than, double quote, and single quote. That set makes text safe in both element content and quoted attributes. Other characters (accents, emoji) don't need escaping in UTF-8 pages.

Does escaping make user input safe against XSS?

It is the correct first step for HTML contexts, and the exact escaping shown here is what template engines do. But context matters: text going into a URL, a script block, or a CSS value needs that context's own escaping instead.

Why does decoding handle entities encoding doesn't produce?

Decoding meets text from the wild - scraped pages, CMS exports, feeds - which use hundreds of named and numeric entities. Using the browser's parser means anything a browser would render decodes correctly here.

What is the difference between ' and '?

The same apostrophe. ' is the numeric form and works everywhere; ' is named and, notoriously, was not defined in HTML4, which is why careful encoders emit the numeric form. This one does too.

Related tools

• base64 ⇄ textBase64 both directions, UTF-8 safe, emoji included.
• url ⇄ textPercent-encoding both ways, component or whole-URL mode.
• jwt decoderDecode JWT header, payload, and expiry - locally, because tokens are credentials.