XML is far stricter than HTML about entities: it predefines only five. This tool escapes those five characters so your text is well-formed inside XML elements and attributes, and unescapes them back to plain characters.
Why XML escaping matters
An XML parser is unforgiving. A single unescaped < or & in text content causes the entire document to be rejected as not well-formed — there is no “best-effort” parsing mode equivalent to a web browser’s HTML lenience. This means that data coming from user input, database fields, or external APIs must be escaped before being embedded in XML output.
The classic failure: a business name field containing Johnson & Johnson written directly into XML produces <name>Johnson & Johnson</name>. The parser stops at the ampersand and rejects the file. The correct form is <name>Johnson & Johnson</name>.
The five predefined XML entities
XML defines exactly five named character references. Unlike HTML — which has hundreds — XML allows no others unless you declare them explicitly in a DTD:
& → & (must escape first, or the later passes create new ampersands)
< → <
> → >
' → '
" → "The order matters for escaping: the ampersand must be replaced before any other character. If you escape < first and produce <, then escape & you would turn < into &lt; — double-escaping the entity. Every correct XML escaper handles ampersand first.
When each entity is strictly required
| Context | Mandatory | Optional but safe |
|---|---|---|
| Element text content | & and < | >, ', " |
| Attribute in double quotes | &, <, " | >, ' |
| Attribute in single quotes | &, <, ' | >, " |
In practice, escaping all five everywhere is the safest approach and is what this tool does by default. Partial escaping creates subtle bugs when the context changes or the XML is re-processed.
Unescape and numeric references
Unescaping reverses the five named references and also expands numeric references such as A (decimal) and A (hexadecimal), both of which represent the letter A. Unknown named entities are left untouched — the tool never silently drops data.
A common trap: HTML entities in XML
If you are generating XML from an HTML templating engine, watch for HTML-only entities leaking in. (non-breaking space), © (copyright symbol), and hundreds of others are valid in HTML but undefined in plain XML. An XML parser will reject them. The safe alternatives are the literal Unicode character (a real non-breaking space character in the file) or the numeric reference   for non-breaking space.
The simplest approach: if you need content that has previously been through HTML processing, decode HTML entities first, then re-escape for XML using only the five valid XML entities.