XML Unescape Online — Decode XML Entities

Decode the five predefined XML entities and decimal/hexadecimal numeric character references back to their original characters. Restore SOAP responses, RSS feeds, and config exports — 100% in your browser.

Input (with XML entities)

Output (decoded)

What is XML Unescape?

XML unescape reverses the entity replacements XML uses for characters that have structural meaning. The five predefined entities — < > & " ' — become their single literal characters, and numeric character references like é or 😀 resolve to the Unicode code points they encode.

SOAP responses, RSS and Atom feeds, configuration exports, and OAuth assertions all carry payloads where every &, <, and > has been escaped for transport. The OpenFormatter XML unescape tool decodes the lot in your browser — no upload, no rate limits — so you can read or process the underlying text directly.

How to XML unescape — 4 steps

Paste escaped text. A whole XML element, an attribute value, or a fragment from a SOAP body — anything that contains &…; entity references.
Click Unescape. The tool resolves numeric character references first, then the named entities, finishing with & last to avoid double-decoding.
Inspect the output. Tag delimiters reappear as literal < and >, ampersands as &, and numeric references as accented characters or emoji.
Copy and process. Use the result for display, logging, downstream parsing, or pasting into the XML Formatter to inspect structure.

Side-by-side example

Escaped input

&lt;message id=&quot;42&quot;&gt;
Tom &amp; Jerry said &apos;hi&apos;
caf&#233; &#x1F600; 5 &lt; 10
&lt;/message&gt;

Decoded output

<message id="42">
Tom & Jerry said 'hi'
café 😀 5 < 10
</message>

Predefined + Numeric

Decodes all five XML predefined entities and every &#NNN; / &#xHHHH; numeric character reference — the complete XML 1.0 escape vocabulary.

Unicode-Aware

Numeric references above U+FFFF resolve correctly via String.fromCodePoint. Emoji, CJK, and supplementary-plane glyphs round-trip without loss.

Client-Side Only

Decoding is regex substitution running in your browser. SOAP responses, OAuth assertions, and config exports never reach a server.

Common use cases

check_circleReading SOAP fault messages and Body content where every angle bracket is escaped
check_circleDecoding RSS and Atom feed item titles and descriptions
check_circleRestoring readable text from XML configuration exports
check_circleInspecting SAML assertions and OAuth XML payloads carried in HTTP responses
check_circleDecoding XML attribute values that contain quoted strings or numeric references
check_circleReading legacy enterprise system exports (banking, healthcare, government XML)
check_circleResolving 😀 and similar numeric references to actual emoji and special characters
check_circleCleaning up double-escaped XML strings in nested response payloads

XML entities vs HTML entities

XML defines exactly five named entities. HTML defines hundreds —  , ©, —, and the rest. If your input came from an HTML document or an HTML email, named entities outside the XML five will pass through this tool unchanged. Use the HTML Unescape tool for the full HTML entity table. Numeric character references (&#NNN; and &#xHHHH;) are identical in both languages and decode the same way here.

Need to escape instead?

Re-escape XML for safe embedding inside element content or attribute values, or chain with our other escape tools — all browser-side.

XML Escape XML Formatter All Escape Tools

Frequently Asked Questions

Which entities does this XML unescaper decode?

All five predefined XML entities — < > & " ' — plus every numeric character reference: &#NNN; (decimal) and &#xHHHH; (hexadecimal). Together those cover every escape sequence the XML 1.0 specification defines for plain text content. HTML named entities like   or © are not part of XML and are not decoded.

What is the difference between a predefined entity and a numeric character reference?

Predefined entities use a name (& for ampersand). Numeric character references use the Unicode code point directly: & (decimal) and & (hexadecimal) both decode to &. Numeric references can encode any Unicode character — 😀 produces the grinning face emoji, é produces é. The tool decodes both forms in the same pass.

Why does the order of replacement matter?

The tool decodes & last on purpose. If &lt; appeared in the input and we replaced & with & first, the result would be < — which we would then incorrectly decode to <. By resolving numeric and named entities before the bare ampersand, &lt; correctly survives as the literal string < in the output.

How does it handle supplementary-plane characters and emoji?

Numeric references above U+FFFF (like 😀 — grinning face) are decoded with String.fromCodePoint, which produces the correct surrogate pair in JavaScript. The result renders as a single emoji or supplementary-plane glyph. CJK characters and accented Latin letters via é or é round-trip without loss.

Can I unescape the contents of a CDATA section?

No need — text inside <![CDATA[ … ]]> is taken literally and never escaped. If you have a value that came from a CDATA section, it is already decoded. This tool decodes entity references in regular XML text and attribute values, not CDATA blocks.

Will the output be valid XML?

No, and that is the whole point. Decoded text contains literal < > & characters that cannot appear in valid XML element content. Treat the output as plain text — for display, logging, or further string processing. If you need valid XML, re-escape with the XML Escape tool.

How do I unescape an XML attribute value?

Paste only the value — the text between the surrounding double or single quotes — into the input. The same five predefined entities and numeric references are used in attribute values, so the same decoder works. Including the attribute name and equals sign produces a result with literal name="..." text in the output.

Is my XML uploaded to a server?

No. Decoding runs in your browser using regular expressions and String.fromCodePoint. SOAP responses, configuration exports, and feed payloads — including any embedded credentials or PII — never leave the page. Verify in DevTools → Network.