HTML Entity Decode

This tool decodes HTML entities back to literal characters. Everything happens in your browser; nothing leaves your machine. For the inverse, see HTML encode.

What HTML entities are

Five characters have special meaning in HTML and must be encoded when used as text content:

Decoding turns these forms back into the bare character. The tool above handles all three forms (named, decimal, hex).

Decimal vs hex character references

Numeric character references work for any Unicode code point:

&     →  &     (decimal 38)
&    →  &     (hex 0x26)
—   →  —     (em dash, decimal 8212)
—  →  —     (em dash, hex 2014)
😀 →  😀    (grinning face emoji, decimal)
😀 →  😀    (grinning face emoji, hex)

Both decimal and hex are valid; hex is more common in modern code because most Unicode references are documented in hex.

Named entities

The named entities (&, ©, ™, etc.) are predefined shortcuts. The full list is huge — over 2,000 named entities in the HTML5 spec. The most common:

The full reference is in HTML entities.

Required vs optional terminator

A character reference is supposed to end with ;. Browsers also accept some references without the trailing semicolon for backward compatibility, but only for a short whitelist of legacy entities and only in some contexts. Strict decoders require the ;.

&       ← always works
&amp        ← works in some contexts (a few legacy named entities), not others

The tool above decodes with the browser’s own HTML parser, so it accepts exactly what browsers accept: legacy entities like &amp without the ; decode, and there’s no warning when one is missing.

What the tool above doesn’t do

• It doesn’t render HTML. Decoding <b>hello</b> produces the literal text <b>hello</b>, not bold-rendered text.
• It doesn’t strip tags. That’s a different operation. If your input is HTML markup and you want plain text, decode entities and strip tags.
• It doesn’t unescape JavaScript-style escapes. A and \x41 are JavaScript syntax, not HTML entities. The tool above doesn’t touch them.

Where you encounter encoded HTML

• JSON APIs returning HTML strings. Some APIs return HTML inside JSON values, which means the HTML’s &, <, > are encoded once for HTML and the whole string is JSON-escaped on top. Decoding requires both passes.
• CSV exports of web data. Spreadsheets and form-export tools often emit HTML-encoded form values that need decoding when imported elsewhere.
• Email plain-text bodies. Some email clients HTML-encode quoted text in plain-text replies. The recipient sees & instead of &.
• Database fields holding HTML. A “store as encoded for safety” approach yields encoded fields in the database; decoding is needed when displaying outside an HTML context.
• Web scraping output. HTML you extract from a page contains entities; decoding gives you the underlying text.

Common pitfalls

• Double-encoding. A string that’s been encoded twice (&) decodes to & after one pass and to & after two. The tool above does one pass; paste the output back in to run a second.
• Mojibake from wrong encoding. Decoding entities is correct; if the underlying byte stream is wrong-encoded (Latin-1 read as UTF-8), no entity decoding will fix it.
• Forgetting that   is not a regular space. It decodes to U+00A0, which looks like a space but is treated as non-breaking by many systems. If your downstream consumer expects regular spaces, do an additional   → space replacement.
• Decoding inside <script> or <style>. Browsers do not decode entities inside those elements — & inside <script> is literal &, not &. If you’re extracting JavaScript from HTML, don’t decode entities inside script bodies.
• Mixing HTML decoding with URL decoding. They’re different. %26 is URL-encoded &; & is HTML-encoded &. A URL inside HTML is double-encoded.

For the encoding direction, see HTML encode. For the entity reference, HTML entities. For URL encoding, URL decode.