XML (Extensible Markup Language) is a text-based data format that represents information as a tree of nested elements marked by tags, with optional attributes on each element. Among data formats, it is the classic self-describing, hierarchical format: the tag names travel with the values, so a document such as <invoice><total currency="EUR">120.50</total></invoice> carries both data and its labels.
XML is a W3C recommendation published in 1998 and derived from SGML. It defines only the syntax, not a vocabulary: each industry or application defines its own element names and rules. That flexibility, combined with mature tooling for validation, transformation and querying, explains why XML remains central in publishing, finance, government exchange, office documents and enterprise integration, even where JSON has become the default for web APIs.
How an XML document is built
An XML document consists of an optional XML declaration, exactly one root element, and any number of nested child elements, attributes, text nodes, comments and processing instructions. Every opened element must be closed, element names are case-sensitive, and attribute values must be quoted.
| Component | Syntax example | Purpose |
|---|---|---|
| Element | <customer>...</customer> | Main unit of structure, can contain text and children |
| Attribute | <price currency="USD"> | Name-value metadata attached to an element |
| Namespace | xmlns:inv="..." | Prevents name clashes between vocabularies |
| CDATA section | <![CDATA[ a < b ]]> | Text that the parser does not interpret as markup |
| Entity reference | & for an ampersand | Escapes reserved characters |
| XML declaration | <?xml version="1.0" encoding="UTF-8"?> | States version and character encoding |
A document that follows these syntax rules is well-formed. A document that also conforms to a declared grammar is valid. The distinction matters: any XML parser can confirm well-formedness, but validity requires a schema and tells the receiver that the content has the expected structure.
Validation and the XML tool family
XML is defined as much by its surrounding standards as by its syntax. These companion technologies let organizations specify, check, navigate and transform documents without writing custom code for every format.
| Standard | Role | Typical use |
|---|---|---|
| DTD | Original grammar language, limited types | Legacy formats, simple document rules |
| XML Schema (XSD) | Strongly typed structural schema | Data exchange contracts, financial and public sector messages |
| RELAX NG | Compact, expressive schema language | Document-oriented vocabularies |
| XPath | Expression language for selecting nodes | Querying and addressing parts of a tree |
| XSLT | Rule-based transformation language | Converting XML to HTML, text or other XML |
| XQuery | Query language over XML collections | Searching and restructuring document stores |
Schema validation is the main reason many regulated exchanges still use XML. A receiver can reject a malformed payment message or tax filing automatically, before any business logic runs, and both parties can share the XSD file as the formal contract for the interface.
XML compared with other data formats
XML competes mainly with JSON for data exchange and with columnar formats such as Parquet for analytics. Each format optimizes for a different combination of readability, expressiveness, size and processing speed.
| Format | Structure | Schema support | Typical strength | Typical weakness |
|---|---|---|---|---|
| XML | Tree with elements, attributes, mixed content | Mature: XSD, DTD, RELAX NG | Validation, documents with mixed text and markup | Verbose, more complex parsing |
| JSON | Objects, arrays, primitive values | JSON Schema, optional | Compact, native to web APIs | No attributes, comments or mixed content |
| YAML | Indentation-based maps and lists | Limited, usually external | Human-edited configuration | Indentation errors, ambiguous typing |
| CSV | Flat rows and columns | None built in | Simple tabular exchange | No nesting, inconsistent dialects |
| Parquet | Columnar binary with nested types | Embedded schema | Analytical scans and compression | Not human-readable |
One feature remains distinctive: mixed content, where text and markup interleave, as in <p>Pay <b>before</b> Friday</p>. JSON has no natural representation for it, which is why XML still dominates document formats such as office files, technical documentation and legal texts.
Parsing models and performance
Software reads XML with one of two main models. A DOM parser loads the entire document into a tree in memory, which allows random access and XPath queries but can consume several times the file size in memory. A streaming parser such as SAX or StAX reads the document as a sequence of events and keeps memory use roughly constant.
- Use DOM parsing for configuration files, messages and documents of up to a few megabytes that need navigation or modification.
- Use streaming parsing for large exports, feeds and logs that can reach gigabytes, where loading the whole tree would exhaust memory.
- Compress XML in transit with gzip, because its repetitive tag names compress very well.
- Convert XML to a columnar format when the data will be analyzed repeatedly, rather than parsing the same files on every query.
In data engineering, XML is usually an interchange format at the edge of a system. Pipelines parse it once, flatten the hierarchy into tables or nested columns, and store the result in a format designed for analytics.
Security risks and common mistakes
XML parsers support features that can be abused by untrusted input, so secure configuration is essential whenever documents come from outside the organization.
| Problem | What happens | Remedy |
|---|---|---|
| XML external entity (XXE) | Entities read local files or reach internal hosts | Disable external entities and DTD processing |
| Entity expansion attack | Nested entities expand into gigabytes of text | Disable DTDs or enforce expansion limits |
| Encoding mismatch | Declared encoding differs from actual bytes | Generate UTF-8 consistently and declare it |
| Unescaped characters | A raw ampersand or angle bracket breaks parsing | Use a serializer, never string concatenation |
| Ignored namespaces | XPath queries return no results | Bind namespace prefixes in the query context |
A frequent design mistake is the inconsistent choice between attributes and elements. A practical rule is to use attributes for metadata about a value, such as a unit, identifier or language, and child elements for the data itself and anything that may need structure or repetition later.
The simple explanation
XML is a way of writing information so that every piece of data comes with a label. A bare number is not enough. An XML file says that this is the price and that the currency is euros. Labels can sit inside other labels, much like folders inside folders.
The rules are strict. A computer can therefore check whether a file is complete and correct before using it. That reliability is why banks, governments and publishers still rely on XML. Newer formats are shorter, but they are not as easy to check.
How it is used in practice
A mid-sized manufacturer must send electronic invoices to public-sector customers in a country that requires a standardized XML invoice format. Its accounting system exports each invoice as an XML file containing seller and buyer details, line items, tax rates and totals, all in the elements defined by the official schema.
Before sending, an integration service validates every file against the published XSD. In the first week, about one invoice in fifty fails because some product descriptions contain unescaped ampersands and a few tax codes are missing. The team switches the export to a proper XML serializer and adds a required-field check upstream.
After the fix, rejected invoices drop to almost zero, and payment delays caused by format errors disappear. The finance team also uses an XSLT stylesheet to render the same XML files as readable PDF copies for its archive.