HTML Entity Encode / Decode

What is HTML entity encoding?#

HTML gives special meaning to a handful of characters: < and > delimit tags, & starts an entity or a character reference, and " and ' quote attribute values. Whenever you want one of those characters to appear as literal text on a page — showing users the source of a code snippet, echoing search input back into a field, displaying the string Tom & Jerry — you have to replace it with a stand-in called an entity. That substitution is HTML entity encoding.

There are three ways to write the same escape, and this tool offers all three through the Options selector:

• Named — & becomes &, < becomes <, and so on. Human-readable, and the only form people normally type by hand. In this mode only the five structurally dangerous characters are escaped; everything else passes through untouched.
• Decimal — every non-ASCII or control character becomes &#N;, where N is its Unicode code point in decimal (for example © becomes ©). Good when you want every non-standard byte to be visible and ASCII-safe.
• Hex — the same idea with hexadecimal code points: © becomes ©. Compact and aligns naturally with the code-point notation you see in Unicode tables.

Decoding recognises the named entities in a curated HTML5 subset, plus &#NN; (decimal) and &#xHH; (hex). An unrecognised named entity is left exactly as-is rather than guessed at — safer than silently emitting the wrong character.

How to use it#

1. Pick Encode or Decode from the toggle at the top-left.
2. Under Options, choose Named, Decimal, or Hex.
3. Paste into the Input pane on the left.
4. Read the escaped (or unescaped) result from the Output pane on the right and click Copy.
5. Sample loads a demonstration string; Clear resets the panes.

Key features#

• Three escape styles from one selector. Switch between named, decimal, and hex without re-pasting, which makes comparing output trivial.
• Astral-character correct. Iteration is by Unicode code point, not UTF-16 code unit, so an emoji like 🌍 is treated as one character (🌍), not a broken pair of surrogates.
• Curated, safe decoder. The named-entity map covers the common HTML5 references (copyright, trademark, accented letters, math symbols, quotes and dashes). Unknown names pass through untouched instead of being mangled.
• No DOM involved. Encoding and decoding are pure string operations — no hidden <div> injection — so the logic is fully testable and there is no risk of the tool itself interpreting your input as markup.

Worked example#

Take a fragment that mixes markup with a literal symbol:

<a href="x">Tom & Jerry</a> © 2026

In Named mode, only the five dangerous characters are escaped and the © is left alone (it is not structurally dangerous):

<a href="x">Tom & Jerry</a> © 2026

Switch to Decimal and the © becomes its code point too, while the core characters switch to numeric form:

<a href="x">Tom & Jerry</a> © 2026

In Hex mode the same characters appear as hexadecimal code points:

<a href="x">Tom & Jerry</a> © 2026

Decoding reverses all of these: paste any of the three outputs back with Decode selected and you get the original fragment, including the ©.

FAQ#

Which mode should I use to make a string safe to put inside HTML?#

Named is almost always the right default for the five dangerous characters — it is readable, well understood by every browser, and keeps the output diff-friendly. Reach for Decimal or Hex when you specifically need every non-ASCII character made ASCII-safe (for example, preparing content for a transport that rejects high bytes), not for ordinary escaping.

I decoded © but a weird name like &mytag; came out unchanged. Why?#

The decoder only resolves entities it actually knows — a curated HTML5 subset of the common names. &mytag; is not a real HTML entity, so the tool leaves it untouched rather than guessing or dropping it. If you genuinely need every DTD-defined entity resolved, you are outside the scope of a string converter and into real HTML parsing.

Is HTML-escaping enough to make user input safe in a JavaScript string or a URL?#

No. Each context has its own rules. HTML escaping protects against injecting markup, but a string like '); alert(1); // is harmless in HTML and dangerous inside a <script>. The same input also needs URL-encoding before going into a link. Escape for the destination context, not just once.

Why does the hex output use lower-case letters (© not ©)?#

Lower-case hex is the conventional, tidier form and is parsed identically by every browser. If you need upper-case for a style guide, the decimal mode (©) sidesteps the question entirely, or run the output through your own case transform.