Decode HTML Entities Online

How to Decode HTML Entities Online

1. Paste Into Input (HTML Entities): Drop encoded HTML or entity-laden text into the left "Input (HTML Entities)" pane. Any mix is accepted — named references like &, <, ©, decimal numerics like ' or ’, and hex numerics like & or —. Plain characters pass through unchanged.
2. Watch the Decoded Output Pane: The right "Decoded Output" pane updates in real time as you type or paste — there is no separate Decode button. Each entity is replaced with its Unicode character (& becomes &, 😀 becomes 😀), and the field is marked Read Only to prevent accidental edits.
3. Spot Double-Encoded Strings (Optional): If the output still shows entity references (for example & rendered as the literal text &), the input was encoded twice. Copy the output back into the input pane to run a second decode pass. Repeat until no &...; patterns remain.
4. Copy and Paste Onward: Select the decoded output and copy. Everything runs client-side in your browser — no upload, no sign-up, no watermark. Sensitive text (XSS proof-of-concepts, scraped customer data, internal docs) never leaves the tab.

Why Decode HTML Entities?

HTML entities exist because the <, >, &, ", and ' characters are reserved in HTML markup. Browsers, CMS template engines, sanitisers, RSS feeds, and scrapers escape them — and sometimes re-escape them — so that the source is safe to embed in a page. When you pull that source out of its rendering context, you want the literal characters back. The XConvert decoder unwinds named references, decimal numeric character references (&#NN;), and hex numeric references (&#xHH;) in one pass.

• Web-scraping output cleanup — BeautifulSoup, Cheerio, and Scrapy often hand back text where ' shows up as ' and " shows up as " (or "). Decoding before you write to a database or CSV avoids double-escaped quotes breaking your INSERT statements.
• Debugging double-encoded CMS output — A WordPress post that renders the literal text & instead of & was encoded twice somewhere in the pipeline — usually a plugin escaping content the template engine already escaped. Running two decode passes confirms the diagnosis before you hunt the filter.
• Reading raw email source and webhook payloads — Plain-text email bodies and webhook JSON sometimes carry HTML-encoded fragments (<a href="...">). Decoding makes the inline links and tags legible without opening the message in a renderer.
• Inspecting XSS proof-of-concepts safely — Entity-encoded payloads from bug bounty reports (e.g. <script>alert(1)</script>) can be decoded to see exactly what would execute, without pasting into a browser address bar where the URL parser might fire it.
• Translating smart-quote noise from Microsoft Word — Pasting from Word into a CMS often produces ’, “, ”, …, and —. Decoding shows the actual curly quotes (’ “ ” … —) so you can decide whether to keep them or normalise to ASCII.
• Round-tripping with the HTML Entity Encoder — Decode once for analysis, edit the plain text, then re-encode exactly once before pasting back into your template. Doing both in the same tool prevents the off-by-one encoding mistakes that cause & bugs.

Common Named Entities You'll Hit

Entity	Character	Unicode	Notes
&	&	U+0026	One of five HTML-mandatory escapes — always encode inside attribute values
&lt;	<	U+003C	Mandatory in element content
&gt;	>	U+003E	Mandatory inside CDATA-like content; commonly escaped everywhere
&quot;	"	U+0022	Mandatory inside double-quoted attribute values
&apos;	'	U+0027	XML/HTML5 named entity; not defined in HTML4 — use &#39; for max compatibility
&nbsp;	(no-break space)	U+00A0	Prevents line wrap; not the same as ASCII space (U+0020)
&copy;	©	U+00A9	Copyright sign
&reg;	®	U+00AE	Registered trademark
&trade;	™	U+2122	Trademark
&hellip;	…	U+2026	Horizontal ellipsis
&mdash;	—	U+2014	Em dash
&ndash;	–	U+2013	En dash
&rsquo;	’	U+2019	Right single quote (Word "smart apostrophe")
&ldquo; / &rdquo;	“ ”	U+201C / U+201D	Curly double quotes from Word/Pages

The full WHATWG named-character reference table lists 2,125+ recognised names — ⋢, ♥, and the rest of the long tail are handled automatically.

The Three Entity Forms

Form	Pattern	Example	When you see it
Named	&name;	& → &	Hand-written HTML, most templating engines, RSS feeds
Decimal numeric	&#NN;	' → '	XML output, JSON-embedded HTML, older HTML4 sanitisers (avoids the HTML4-undefined ')
Hex numeric	&#xHH;	😀 → 😀	Modern serialisers, security tooling, anywhere astral-plane / emoji code points appear

All three forms have been part of the HTML spec since HTML 2.0 (1995) — every browser shipped in the last 25 years decodes them. The XConvert decoder treats them interchangeably.

Frequently Asked Questions

Why is my scraped HTML full of & and ' instead of & and '?

The page you scraped served pre-escaped HTML so the characters wouldn't be misinterpreted as markup or quote terminators. Browsers decode these automatically before display, but tools like requests.get(url).text in Python, fetch(url).text() in JavaScript, or curl give you the raw source — entities and all. Run the text through a decoder (or call html.unescape() in Python, or use an HTML parser like BeautifulSoup with .get_text() which auto-decodes) before storing it.

Is it safe to decode an XSS payload here?

Yes — the decoder is pure string substitution running in your browser tab. It produces text, not a live DOM, so a decoded <script> tag does not execute. The output pane is a read-only <textarea> that displays the characters literally. That said, do not then paste the decoded result into an HTML page's innerHTML or a templating engine without re-escaping — that's exactly the XSS path the encoding was preventing.

Are numeric entities (&#NN;, &#xHH;) supported everywhere?

Yes. Decimal and hex numeric character references have been in the HTML spec since the earliest versions and every shipping browser handles them. They cover the full Unicode range — 💩 produces 💩, 😀 produces 😀 — without needing the named-entity table. If you're emitting HTML and worried about old-CMS compatibility, numeric references are the safest choice.

What's the difference between   and a regular space?

  decodes to U+00A0 (no-break space). It renders the same width as a normal space, but it tells the layout engine "do not break the line here" — useful for keeping a number with its unit ("10 kg") or a name with its title ("Dr. Smith"). After decoding, the character is a regular character in your text but is not equal to U+0020 — string comparisons (str == "10 kg") and .split(' ') calls will silently fail. Normalise with a regex like s/[ \s]+/ /g if you need plain spaces.

Why do ’, “, and … keep showing up in content pasted from Word?

Microsoft Word and Pages auto-correct straight ASCII quotes/dashes into typographic ("smart") variants: ' → ’ (U+2019), " → “ ” (U+201C/201D), ... → … (U+2026), -- → — (U+2014). When that text round-trips through an HTML editor that escapes non-ASCII characters, you see the entity names instead of the glyphs. Decoding reveals the actual curly characters; if you want plain ASCII, run a follow-up replace step (’ → ', etc.).

Can I decode HTML entities in JavaScript without a library?

Yes, using the "textarea trick" — the browser's own HTML parser decodes entities when you assign to innerHTML:

function decodeEntities(s) {
  const t = document.createElement('textarea');
  t.innerHTML = s;
  return t.value;
}

Setting innerHTML on a <textarea> (rather than a <div>) is the safe variant: the textarea will not execute <script> tags or fire image onerror handlers contained in the input — they become inert text inside the textarea's value. On the server side or in modern frontend code, the he library is the standard choice; in Python, html.unescape() from the standard library; in PHP, html_entity_decode($s, ENT_QUOTES | ENT_HTML5, 'UTF-8').

My input has & — why?

The text was HTML-encoded twice. Somewhere in the pipeline, content that already contained & (the encoded form of &) was treated as if it were raw text and encoded again: the & in & became &, producing &. One decode pass gives you &; a second pass gives you &. Find the duplicated escape call — common culprits are a CMS plugin escaping content the template engine has already escaped, or a JSON-in-HTML serialiser that double-encodes before injecting into a data- attribute.

What happens to malformed or unknown entities?

Anything that doesn't match a known named reference or a valid numeric pattern is left in the output unchanged — so &notarealentity; stays as &notarealentity;, and a stray ampersand like Q&A (no semicolon, no defined name) stays as Q&A. This makes broken entities visible at a glance instead of silently dropping characters. The HTML5 parser is somewhat more lenient with missing semicolons for legacy named entities (e.g. &amp without ; may still be recognised in attribute context); the XConvert decoder follows the strict-with-semicolon form to avoid surprising you.

Can I encode the result back to HTML entities?

Yes — use the HTML Entity Encoder for the reverse direction. Together they cover round-trip workflows. For related encoding tasks, see URL Decoder for %XX percent-encoded URLs and Base64 Decoder/Encoder for ==-padded base64 strings. If you're cleaning HTML output for downstream text pipelines, HTML to Markdown strips the tags entirely and decodes entities in one step.