XML looks intimidating in bulk, but every document is built from the same small set of pieces. Learn the pieces and any document becomes readable.
The parts
At the very top there may be an XML declaration: <?xml version="1.0" encoding="UTF-8"?>. It is not an element; it just states the version and how the bytes are encoded. It is optional, but when present it must be the first thing in the file.
The body is elements. An element is a start tag, some content, and a matching end tag: <title>XML Guide</title>. Elements can contain text, other elements, or nothing. An element with no content can be written as a self-closing tag: <break/> means the same as <break></break>. Every document has exactly one outermost element, the root, and everything else nests inside it, which is what makes XML a tree.
Elements carry attributes in their start tag, as name and quoted value pairs: <book id="bk101" lang="en">. Attributes describe the element; the values are always quoted. Between tags sits text content, the actual data: the XML Guide inside the title.
Reading top to bottom
To read a document, start at the root and walk inward. Each start tag opens a branch; its matching end tag closes it; indentation usually mirrors the nesting depth. Ask three questions of each element: what is it called, what attributes does it carry, and what does it contain, whether that is text or more elements. That is enough to reconstruct the whole shape.
A few characters are special and appear as escapes rather than literally: < for a less-than sign, & for an ampersand, >, ", and '. These are the built-in entities, and they exist because a bare < or & would otherwise be read as the start of a tag or an entity.
Beyond elements and attributes there are three special constructs, comments, (character data) sections, and processing instructions, each covered in its own article. And when the same element names could clash between vocabularies, namespaces disambiguate them. But the backbone is always the same: a single root, elements nesting inside elements, attributes on the tags, and text at the leaves.
Order matters in ways that surprise people from JSON
XML has document order, and it is significant: sibling elements are a sequence, not a set. Two documents with the same elements in a different order are different documents, which is exactly the opposite of the intuition JSON object keys build.
That has a practical edge in signing and comparison. Canonicalisation exists because two logically identical XML documents can differ byte for byte (attribute order, whitespace, namespace declarations), and a signature covers bytes. This is why XML signature verification is subtle in a way that JSON signing is not, and why a document that "looks the same" can fail verification for reasons invisible in a diff.
This series, in order
This article opens the series XML and its hazards. Once each part of a document has a name, the series moves from what a parser insists on, through the vocabulary and constructs that confuse readers, to the entity declarations that let a document attack the parser reading it.
- Well-Formed vs Valid XML. The baseline a parser enforces before anything else (one root, matched tags, quoted attributes), and how validity differs.
- XML Namespaces Explained. Two vocabularies, one element name: the prefix is a local shorthand and the URI is the identity.
- CDATA, Comments, and Processing Instructions. The three things in a document that are not elements, and what each one is for.
- XXE and External Entities. How an external entity makes a parser read local files or make requests, and the blunt fix: refuse the DOCTYPE.
- Billion Laughs and Entity Expansion. Entities that multiply each other until a tiny document fills memory, and how to cap or refuse it.
- XXE and Why a SAML Parser Rejects DOCTYPE. Both attacks traced to the DTD, and why a hardened decoder rejects any DOCTYPE instead of parsing it carefully.