What XML is, how it differs from HTML and JSON, and where it still runs the world

XML was going to be the universal format for everything, and for a few years around 2000 it nearly was. Today most new APIs use JSON, but XML quietly underlies Office documents, SVG, RSS feeds, sitemaps, Android layouts and most enterprise integration. Reading it is a useful skill; the XML formatter makes it readable and reports where it's broken.

What XML is

Extensible Markup Language (W3C, 1998) is a text format for tree-structured data: elements with a start tag, content and an end tag, nested inside one another, with attributes on the tags. It defines no tags of its own — "extensible" means each application defines its vocabulary — and its strictness was the point: unlike HTML of the era, which browsers forgave, an XML parser rejects any document that breaks the rules, so software can rely on the structure.

Well-formed: the rules

<?xml version="1.0" encoding="UTF-8"?>
<order id="1042">
  <customer>Ada Lovelace</customer>
  <item sku="A-7" qty="2">Analytical engine part</item>
  <note/>
</order>

• Exactly one root element.
• Every start tag has a matching end tag (or is self-closing: <note/>); tags close in the reverse order they opened.
• Tag names are case-sensitive; attribute values are quoted.
• Five characters are special and must be escaped in content: &lt; &gt; &amp; &quot; &apos; (the entities tool converts them).
• The optional declaration states the encoding (UTF-8 explained: how text is stored, and why it turns into é and ’).

A document obeying these is well-formed; one that also matches a schema is valid. Most "XML errors" are a missing end tag or an unescaped ampersand in a URL.

Elements, attributes, namespaces, schemas

Data can go in child elements or in attributes; the convention is attributes for metadata (ids, types) and elements for content, but vocabularies differ and it's the first thing to check when reading a new one. Namespaces (xmlns="…") let one document mix vocabularies — an SVG inside an HTML page, Office's dozen sub-formats — by prefixing element names with a URI-identified vocabulary. Schemas (DTD, XML Schema, RELAX NG) describe what a valid document may contain, and validators enforce them, which is why XML persists in regulated exchange: a bank file that doesn't match the schema is rejected before a human sees it.

Why JSON won for APIs

XML's verbosity (every value wrapped in an opening and closing tag), its impedance mismatch with program data (is this an element, an attribute, text?), and the heavy toolchain around it (SOAP, WSDL, XSLT) made web developers reach for JSON, which maps directly onto the objects and arrays in JavaScript and every other language (What JSON is, and where it trips people up). By 2010 JSON was the default for new web APIs; by 2020 it was rare to see XML in one. The remaining strengths — schemas, namespaces, mixed content (text with markup inside it), comments, and mature validation — are precisely the things document formats need and APIs mostly don't.

Where XML still lives

• Office files: .docx, .xlsx and .pptx are ZIP archives of XML (CSV vs Excel: what each file really contains, and what breaks in between, Word to PDF reads one).
• SVG (What an SVG is, why it scales forever, and when not to use it) and MathML, XHTML.
• Feeds: RSS and Atom, still how podcasts are distributed.
• Sitemaps (the sitemap generator) and robots-adjacent files search engines read.
• Configuration: Android manifests and layouts, Maven, .NET project files.
• Enterprise and government exchange: banking (ISO 20022), healthcare (HL7 CDA), publishing (DocBook, JATS), where schemas are the contract.

Converting is straightforward for simple documents — XML to JSON and JSON to XML — and lossy for the features JSON lacks (attributes versus elements, mixed content, namespaces), which the converters flatten by convention.