XML uses angle brackets and the ampersand to mark up tags, so those characters can't appear raw inside text content — the document stops being valid XML, and unlike a browser rendering broken HTML, an XML parser refuses to process it at all.
The five required entities
Unlike HTML, which defines hundreds of named entities, the XML specification requires only five:
<— for<>— for>&— for&'— for a single quote'"— for a double quote"
Quotes only need escaping inside attribute values, while < and & must be escaped anywhere in text content.
Where this actually shows up
RSS and Atom feeds are plain XML, so a blog post title like "Tips & Tricks" breaks the entire feed for every subscriber's reader unless the ampersand is escaped. The same rule applies inside SOAP requests, still common in banking and enterprise integrations, and inside Office Open XML — the format behind .docx and .xlsx files, where every paragraph of text is stored as XML with these same five entities under the hood.
Why XML is stricter than HTML
Browsers generally tolerate broken HTML and try to render the page anyway. XML parsers don't: one unescaped ampersand or angle bracket makes the whole document invalid, and processing stops with an error instead of a best-effort guess.
When you need this
- Preparing user-supplied text before inserting it into an XML document (feeds, config files, SOAP messages).
- Debugging: seeing the raw text hidden behind entities in a received XML payload.
- Hand-editing XML files where breaking the document structure isn't an option.
The entity alternative: CDATA sections
When a block of text contains many special characters — a chunk of HTML or code embedded inside XML — it's often cleaner to wrap it in <![CDATA[...]]>, where < and & don't need escaping and are treated as plain text. The one exception is the sequence ]]>, which closes the CDATA section and therefore can't appear inside the content itself.