HTML Decoder

Where entity-encoded text comes from

Encoded text has a way of finding you. CMS exports escape article bodies so they survive the journey; RSS and Atom feeds wrap titles and descriptions in entities; database dumps from older systems store &amp; where a plain & belongs. Copy source out of a browser's "view source" panel and every < arrives as &lt;. API responses, especially from XML-based services and legacy backends, routinely double as entity soup.

In every case the entities were correct at the boundary they were protecting — the problem is that you now need the text itself: to edit it, to migrate it, to search it, or to paste it somewhere that does its own escaping. That is the decoder's job.

A concrete scenario: you export ten thousand product descriptions from an old shop platform and every apostrophe arrives as &#039;, every price as &pound;9.99. Re-importing that data as-is means your new storefront literally displays "&#039;" to customers. Running the export through a decoder first — one pass, maybe two — restores the clean text before it touches the new database. The same applies to migrating blog content, cleaning scraped data, or making sense of an XML API response buried in entities.

The double-encoding trap

The single most common decoding scenario is text that was escaped twice. A CMS encodes an article on save; a template encodes it again on render; the page then displays the literal string "&lt;p&gt;Hello&lt;/p&gt;" to visitors. One decode pass turns &amp;lt; into &lt; — still an entity. Only a second pass recovers the original < character.

This tool detects the situation automatically: when the decoded output still contains entities, a "Decode again" chip appears so you can run another pass with one click, with a counter tracking how many layers you have peeled. Triple-encoded exports from pathological pipelines are handled exactly the same way.

How browsers parse entities — and why it matters

Entity parsing has surprising edge cases that trip up hand-rolled decoders. The HTML5 specification allows certain named entities to appear without a trailing semicolon in text (&amp followed by a space still decodes to &), defines over two thousand named references, and lets numeric entities reach any Unicode code point — &#128512; is a perfectly valid grinning face. Regex-based decoders routinely miss all three cases.

That is why this tool decodes through the browser's own HTML parser rather than a lookup table: whatever Chrome, Firefox or Safari would render from an entity is exactly what you get back. The parse happens in a detached element that is never inserted into the page, so nothing in the input can execute — the parser is used purely as an entity resolver.

A related subtlety: decoding is not always idempotent from the user's perspective. If the decoded text itself contains entity-shaped strings — common after double encoding — the result still is not the original. Rather than guessing how many layers exist, this tool decodes one layer at a time and tells you when another pass would change the output, so you stay in control of how far the unwrapping goes.

All three entity forms, one decoder

HTML entities come in three flavors: named (&amp;, &nbsp;, &euro;, &hellip; — over two thousand in the HTML5 spec), decimal (&#8364;) and hexadecimal (&#x20AC;). Browsers treat them identically, and so does this tool — decoding runs through the browser's own HTML parser, so the complete named set plus both numeric forms resolve correctly, including obscure entries like &ThickSpace; and astral-plane characters.

When decoded text is actually markup you intend to use, the rendered preview shows what it will look like — sanitized and sandboxed, with scripts, event handlers and forms stripped, so you can inspect third-party HTML without executing it. Preview is for inspection only; sanitize again in your own pipeline before publishing decoded markup from untrusted sources.