HTML Decoder & HTML Encoder – Decode HTML Online

Decode HTML entities online

Switch to Decode → Text, paste something like <p>Tom & Jerry</p> and this HTML decoder gives back <p>Tom & Jerry</p>. It runs in your browser as you type, so nothing you paste is uploaded.

You will see this job called several things. HTML decode, HTML unescape and HTML entity decoder all mean turning entities back into the characters they stand for; people looking to decode HTML online usually have text copied from page source, an RSS feed, a JSON API response or a database column that was escaped once too often. Some call it an HTML deobfuscator when a page hides an email address or a snippet behind numeric entities such as mail — decoding reveals that text, but it does not unpack minified or obfuscated JavaScript.

What an HTML encoder actually protects you from

A browser cannot tell your markup apart from markup that arrived in a comment box. It parses whatever it is given. An HTML encoder is how you say “treat this as text”:

That is the whole mechanism behind escaping user content, and why an HTML encoder sits in the output path of almost every web framework. Six characters do all of it:

<

Opens tags. Left raw, comments containing <script> stop being text and become markup your browser runs.

>

Closes tags. Escaped mainly for symmetry, and because some parsers will happily repair half-broken tags for an attacker.

&

Starts every HTML entity, so it goes first. Escape it last and you re-escape ampersands you just created.

"

Ends double-quoted attribute values, letting anything after it become a new attribute — onerror, say.

'

Ends single-quoted attributes in exactly that way. Written numerically because &apos; is not in HTML 4 and older parsers ignore it.

`

Not special in HTML itself, but old versions of IE accepted backticks as attribute delimiters. Cheap to escape, so it is escaped.

Escaping is per context, not per value

This is what catches people out. Values are not “escaped” in general — they are escaped for somewhere. One string needs different treatment depending on where it lands, and the wrong scheme gives all the comfort of having escaped something with none of the protection:

HTML body text

What this HTML encoder is built for. Escape those six characters and user content renders as whatever someone typed.

An attribute value

Same HTML entities, but quote your attribute too. An unquoted attribute can be ended by a space, which no amount of escaping prevents.

Inside a <script> block

HTML entities do not help — JavaScript parsers never decode them. Serialise your value as JSON instead, or pass it through a data attribute and read it from the DOM.

A URL or query string

Percent-encoding, not HTML entities. Different alphabets solving different problems; neither substitutes for another.

Inside a style block

Neither scheme is enough. CSS has its own escape syntax and its own injection routes, so never build style rules out of user input.

If your destination is a link rather than a page, you want the URL encoder instead — ampersands are & in markup but %26 in URLs. Escape once, for the right destination, at the moment you write that value out.

Named, numeric and hex entities

Every character has three ways of being written as an HTML entity. An ampersand is & by name, & by decimal code point and & by hex. All three decode identically, and this HTML decoder accepts all three.

Named HTML entities read better, but only five are defined in XML: &, <, >, " and '. HTML defines well over a thousand more, which is why   works in web pages and breaks RSS feeds. Numeric HTML entities are safe everywhere, so they are your right choice for XML, SVG and anything you cannot inspect.

Note that this HTML encoder writes ' rather than ' for an apostrophe, for exactly that reason — numeric HTML entities have always worked, and ' was not part of HTML 4.

Double encoding, and what this HTML decoder will not do

Seeing < on a page means something escaped an already-escaped string. One pass turned < into <; a second read that ampersand as an ordinary character and turned it into &, so your reader gets literal text instead of a tag. Almost always some template escaped a value your framework had already escaped. Decode twice here to confirm, then remove one layer.

One honest limit: this HTML decoder handles numeric and hex entities in full, plus the couple of dozen named HTML entities you actually meet —  , ©, — and friends. HTML defines far more, so rarer named entities such as ö pass through unchanged rather than becoming ö. If HTML entities survive a decode, that is why — and the numeric form of that character decodes correctly.

Decoding is also not a security step. An HTML encoder protects whatever page displays your value; decoding hands back original characters, tags and all. Never decode untrusted input and then insert that result into your page — it undoes the protection an HTML encoder just gave you.