Unescape XML entities
Turn entity references back into characters, including numeric forms such as   and  , so escaped markup becomes readable again.
- Runs in your browser
- Nothing you enter is sent
- Free, no account
Your XML never leaves this tab — check it yourself—
Starting the network probe…
The counter above wraps fetch, XMLHttpRequest and navigator.sendBeacon in this tab and counts every call. It does not block anything — it just reports.
Two ways to verify independently
- Turn off Wi-Fi or enable airplane mode, then use the tool. It keeps working, because the page is already fully loaded.
- Open your browser devtools, switch to the Network tab, clear it, and run the tool. No new row appears.
Why this matters
In 2025 researchers found that popular online formatters had retained tens of thousands of user-submitted snippets — JSONFormatter.org and CodeBeautify together exposed roughly 80,000 saved documents, many containing live cloud credentials, private keys and internal database connection strings, because “format this” quietly meant “upload this”. A separate incident exposed roughly 3.5 million user PDFs on a document-conversion service. The only structural fix is not sending the data in the first place: this site is served under a Content-Security-Policy whose connect-src contains no third-party origin, so a request off this device cannot be made even by accident.
What gets decoded
- The five XML built-ins:
&,<,>,",'. - Decimal references:
 ,—— any codepoint. - Hexadecimal references:
 ,—, in either letter case. - Common HTML named entities that turn up in escaped XML: nbsp, copy, reg, trade, hellip, mdash, ndash, the curly quotes, the guillemets, and the main currency and degree signs.
Anything that looks like an entity but is not recognised is left exactly as written rather than
deleted. Silently dropping an unknown &foo; would destroy data, and it is
frequently not an entity at all — it is a query string that was never escaped in the first place.
Double escaping, and how to spot it
If your text contains &amp; or &lt;, it passed through
two layers that each escaped it. This happens constantly in pipelines: a value is escaped when
written into a database, escaped again when rendered into a template, and arrives with the
ampersands multiplied. Unescape repeatedly until the text stops changing — then fix the pipeline,
because a double-escaped value will eventually meet something that unescapes once and displays
the rest as literal text.
The opposite bug is worth naming too: text that was unescaped one time too many, and now contains
raw < characters that will break the next document it is written into. Unescape to
read; escape before you write.
Turning escaped markup back into a document
A very common task is recovering an XML document that was stored as text inside another XML document or inside a log field. Unescape it here, then paste the result into the XML validator to confirm it is well-formed and into the formatter to make it readable. If the recovered document is still escaped, run this again — see the section above.
Numeric references and what they mean
| Reference | Character | Where it turns up |
|---|---|---|
  /   | Non-breaking space | Content pasted from HTML or Word; looks like a space but is not one |
’ / ’ | Right single quote | Apostrophes autocorrected by a word processor |
— / — | Em dash | Editorial content |
 /  | Byte-order mark | An invisible character that breaks the XML declaration |
| Line feed | Multi-line values stored in an attribute |
A non-breaking space decoded here looks identical to a normal space in the output box. If you are chasing a “why does this comparison fail” bug, that is very often the answer.
Questions
Which entities are decoded?
The five XML built-ins, every decimal reference ( ), every hexadecimal reference ( ), and the two dozen HTML named entities that appear most often in escaped XML — nbsp, copy, mdash, the curly quotes and the currency signs. Anything unrecognised is left exactly as written rather than silently deleted.
My text has &amp; in it. What is going on?
It was escaped twice — a very common bug when a value passes through two layers that each escape it. Run the unescape twice, then fix the pipeline so only one layer escapes.
Does unescaping make my markup unsafe?
It can, in the sense that the result is no longer safe to paste back into an XML document without re-escaping. Unescape to read a value; escape again before writing it anywhere.
Will it turn escaped markup back into working XML?
It will produce the original characters, so `<a/>` becomes `<a/>`. Whether the result is a well-formed document depends on what was escaped — paste the output into the XML validator to find out.