Comparison
CDATA vs escaped text
Both produce the same character data. CDATA changes how the source is written, not what the XML tree contains, and its own terminator creates a limit escaping does not have.
A CDATA section is parser convenience, not a data type. After parsing, <![CDATA[A & B]]> and A & B are the same text node with the same string-value. An XPath expression, schema validator, or XML-to-JSON converter normally cannot tell which spelling the source used.
The choice is therefore about authorship. CDATA is easier for long blocks containing many ampersands and angle brackets. Escaped text is composable, works in attributes as well as element content, and has no forbidden terminator hiding inside user data.
Neither form makes embedded markup active. A <b> written inside CDATA is text, exactly as <b> is text. Use real child elements when the markup is meant to be structure.
What actually differs
| Aspect | CDATA | Escaped text |
|---|---|---|
| Parsed value | Ordinary character data | The same ordinary character data |
| Escaping inside | < and & may appear literally | Write < and & |
| Forbidden sequence | The CDATA terminator cannot appear | No equivalent terminator |
| Attributes | Not allowed in an attribute value | The only available form |
| Nested markup | Treated as text | Treated as text when escaped |
| Round trip | A serializer may replace it with escaped text | A serializer may choose either spelling |
Shown, not asserted
The differences above are claims, so here they are being made. Every one of these runs on each test run, against the same engines the tools use — the outputs are what came back, not what we expected.
A CDATA section accepts markup-looking characters as ordinary text.
document.xml <message><![CDATA[5 < 7 & safe]]></message>What came back
Well-formed. CDATA accepts it.Escaping produces a well-formed document carrying the same visible characters.
document.xml <message>5 < 7 & safe</message>What came back
Well-formed. CDATA accepts it.Literal text without either protection fails at the first bare ampersand.
document.xml <message>5 & 7</message>What came back
xmlParseEntityRef: no name (line 1)
Which to pick
CDATA, when
- A long element body contains many literal < and & characters, such as a code sample.
- Humans maintain the source and CDATA makes that particular block materially easier to read.
- You control the content and can guarantee or split any ]]> sequence before serialization.
Escaped text, when
- The value may appear in an attribute, where CDATA is not syntax.
- The content is untrusted or arbitrary and may contain the CDATA terminator.
- A serializer already handles escaping, so introducing a second source spelling adds no value.
Where it reaches
- ToolsXML escape & unescapeTurn arbitrary text into the escaped form, and reverse it.
- Parse errorsUnescaped ampersand (EntityRef: expecting ';')The other bare-ampersand message, when text after it resembles an entity name.
- Parse errorsSequence ']]>' not allowed in contentThe terminator sequence that remains forbidden in either source form.
- ToolsXML to JSON converterSee both source spellings collapse to an ordinary string value.
Related comparisons
- XML vs JSONJSON won the API era and XML still runs the documents. The difference that decides it is not verbosity — it is that JSON has no way to represent text interleaved with structure.
- Attributes vs child elementsThe oldest argument in XML, and the only parts of it that are not taste: attributes cannot repeat, cannot nest, and cannot be extended later.
Get started
Bring order to the XML your team can't afford to ignore.
Create a free account and get a private workspace to search, validate, diff, and monitor your XML feeds, sitemaps, schemas, and vendor integrations.