HTML Decoder

About the HTML Decoder

Paste text containing entities like &, <, ", or numeric codes like ', and they're converted back to their original characters instantly. Decoding happens through a sandboxed <textarea> element that only ever reads out plain text, so pasting hostile markup can't execute anything or affect the page.

No part of this touches a server, the conversion runs locally the moment you type or paste.

Why a <textarea> element, and not a lookup table

The decoding logic is two lines: create a detached <textarea> that's never inserted into the visible page, assign your pasted text to its innerHTML, then immediately read back its .value. This works because a textarea's content model is defined by the HTML spec as RCDATA — the browser's own parser decodes any entity inside it exactly the way it would anywhere else in a document, but it does not interpret tags as elements. Set <b>&amp;</b> as the innerHTML and reading .value back gives you the literal string <b>&</b> — the ampersand entity resolved, the angle brackets left untouched as plain characters, nothing rendered or executed. That single quirk of the RCDATA content model is what makes this a full, spec-accurate decoder in two lines instead of a hand-rolled regex trying to enumerate every entity name.

It decodes far more than &, <, and "

Because the actual browser parser is doing the work, this isn't limited to the five basic XML entities. It correctly resolves the full HTML5 named character reference table — over 2,000 names including things like ♥, ™, ©, α, and   — as well as both numeric forms: decimal references like © and hexadecimal references like ©, both of which resolve to the same © character. A hand-written regex swap table would need to be kept in sync with the W3C's entity list; delegating to the browser means it's always as current as the browser itself.

Unrecognized entities are left alone, not stripped

If the pasted text contains something that looks like an entity but isn't valid — a stray ampersand in "Q&A" that was never actually encoded, or a typo like &amps; — the parser doesn't error or delete it. It leaves the text exactly as written, since an unmatched entity name simply isn't recognized as one. This graceful fallback means running plain, unencoded text through the decoder is a safe no-op rather than something that could mangle it.

Double-encoded text needs a second pass

If a string has been HTML-encoded twice — for example by two different systems each escaping output independently — you'll see something like & where the literal ampersand should be. One pass through this decoder resolves that to &, which is a valid entity in its own right, not yet the plain & you probably want. Paste the output back into the input box a second time to fully unwind double-encoded text; the tool doesn't loop this automatically since a single decode pass is the mathematically correct behavior for once-encoded input, and auto-looping would incorrectly mangle text that was only meant to display a literal &.

Common situations where you'll run into encoded HTML

Entities show up most often when text has passed through a system that escapes special characters for safe display inside markup — a CMS storing a blog post body, an RSS or Atom feed, a JSON API response that embeds HTML as a string field, or the "view source" output of a webpage where the server-rendered HTML itself contains encoded entities describing further nested content. Developers debugging a scraped page, a broken email template, or a feed that's rendering literal <p> tags instead of actual paragraphs typically reach for a decoder like this one to see what the underlying content actually says, without needing to open dev tools or write a one-off script just to strip a handful of entities.