HTML Decoder

How to Use the HTML Decoder

Paste text containing HTML entities like &, <, or ", then click "Decode HTML Entities." Every recognized entity is converted back into its original character, turning escaped markup back into readable text. Use "Copy Text" to grab the decoded result to your clipboard.

Worked Example

The default text loaded in the box, <div class="box"> & 'quotes' </div> (69 characters), decodes to <div class="box"> & 'quotes' </div>, exactly 35 characters. This is precisely the reverse of the example on this site's HTML Encoder tool, encoding that 35-character string produces this 69-character encoded version, and decoding it here reproduces the original exactly.

Named vs Numeric Entities

Named entities use a recognizable word between & and ;, like & for an ampersand, < for less-than, or © for a copyright symbol. They're easier for humans to read in raw source code, which is why they're the more common style in hand-written HTML.

Numeric entities reference a character by its Unicode code point instead, either in decimal (' for an apostrophe, code point 39) or hexadecimal (' for the same apostrophe, in hex). Numeric entities can represent any Unicode character, including ones that don't have a named entity at all, which is why they're common in machine-generated HTML, API responses, and automated export tools. This decoder handles both forms identically, without needing to know in advance which style a given piece of text uses.

Common Mistakes and Limitations

A frequent point of confusion is pasting text that's been encoded more than once. If a string was accidentally run through an encoder twice, decoding it once here will leave one layer of encoding still in place (you'll see &amp;lt; instead of a clean < or <). If your decoded output still contains entity-looking text, run it through the decoder a second time to strip the remaining layer, repeating until the output stops changing.

Another limitation is that this tool decodes entities but does nothing else, it won't strip actual HTML tags, sanitize content, or otherwise validate the result. If your input contains a real script tag written as literal encoded text, decoding it will produce the literal characters back as plain text in the output box, harmless as displayed text here, but exactly the kind of raw markup you'd need to handle carefully, either escape it again or run it through a proper sanitizer, before ever inserting it into a live web page.

Real-World Use Cases

Reading scraped or exported web content: converting HTML-encoded text pulled from a web page's source, an RSS feed, or a CMS export back into normal readable text.

Working with API responses: decoding entity-encoded fields returned by an API or database export so the content displays correctly elsewhere, without needing to write custom decoding code for a one-off task.

Debugging encoding issues: checking exactly what a piece of encoded text decodes to, useful when troubleshooting double-encoding bugs or verifying an application's own decoding logic behaves the way you expect it to before shipping a fix.

Reversing this site's HTML Encoder: the two tools are natural companions, encode text to make it safe for display, decode it back to recover the original when needed.

Encoding and Decoding as a Round Trip

Encoding and decoding are designed to be perfect inverses of each other: running text through the encoder and then immediately through the decoder should always reproduce the exact original text, character for character, with no loss of information. This property is what makes HTML entities a safe and reliable mechanism, a browser can encode dynamic content for safe display, and later a script or tool can decode it back to the original value without any ambiguity about what the original characters were. If you ever find that an encode-then-decode round trip doesn't reproduce your original text exactly, that's usually a sign the input contained a character combination outside what standard HTML entities were designed to represent, worth double-checking the source text for stray control characters or an encoding mismatch (like content saved in a non-UTF-8 character set) rather than assuming the tools themselves are behaving incorrectly. This round-trip guarantee is also a quick way to test whether your own hand-written encoding logic is correct, if encoding then decoding your test input doesn't return exactly what you started with, something in your logic needs a closer look.

Frequently Asked Questions

Is it safe to decode HTML from an untrusted source here?

Yes, decoding happens using a text-only browser API that never renders the result as live HTML or executes any script, the output box always shows plain text, so nothing decoded here can run in your browser.

Does this handle numeric entities like &#39;?

Yes, both named entities (like &amp;) and numeric entities (like &#39; for an apostrophe) are decoded correctly.

How does the decoder work under the hood, since it never renders HTML?

The tool creates an off-screen, never-inserted-into-the-page textarea element and assigns your input to its innerHTML property, then immediately reads back its value property. Setting innerHTML causes the browser's HTML parser to decode entities as it always does, but a textarea's content is treated as plain text data (RCDATA), never as executable markup, so even a decoded <script> tag or event handler attribute stays inert as text, it's read back as a harmless string, never executed.

What entities beyond &, <, >, ", and ' can this tool decode?

Since decoding relies on the browser's own built-in HTML parser rather than a fixed lookup list, this tool correctly decodes the full range of HTML named entities the browser supports (like &copy; for the copyright symbol or &nbsp; for a non-breaking space) as well as any numeric character reference in decimal (&#169;) or hexadecimal (&#xA9;) form, not just the five most common ones covered by the matching HTML Encoder tool.

Why would encoded HTML end up in my text in the first place?

The most common source is copying text out of a web page's source code, an RSS/XML feed, an API response, or a CMS export, all of which frequently store content in its already-HTML-encoded form. Email newsletter HTML, scraped web content, and old database exports are other frequent sources of entity-encoded text that needs decoding back to plain readable characters before it's useful elsewhere.

Will decoding break text that has a literal & or < that wasn't meant as an entity?

A plain, standalone & or < that isn't part of a recognized entity pattern (like & or <) is left completely unchanged by the decoder, since the browser's parser only recognizes and converts complete, valid entity sequences. Only text that matches an actual entity pattern gets decoded, everything else passes through untouched.