JSON vs XML: Why JSON Won the Data Format Wars

The XML Moment

XML (Extensible Markup Language) was standardised by the W3C in 1998 and spent the next five years as the aspirational universal data format. It was designed to be self-describing, extensible, and platform-neutral — capable of representing any structured data in a format that both humans and machines could read. The promise was compelling: one format for configuration files, database exports, document storage, messaging protocols, and web APIs.

XML achieved significant adoption. SOAP (Simple Object Access Protocol) — the dominant web services protocol of the early 2000s — used XML for all messages. RSS and Atom (feed formats) used XML. Many enterprise systems still use XML today. The W3C produced dozens of XML-based standards: XHTML, SVG, MathML, XSLT, XQuery, XML Schema, and more.

The Problems with XML

Despite its theoretical advantages, XML had practical problems that became more apparent as web applications grew in sophistication:

Verbosity

XML is extremely verbose. The same data expressed in XML and JSON looks like this:

XML:

<user>
  <name>Alice</name>
  <age>30</age>
  <active>true</active>
</user>

JSON:

{"name":"Alice","age":30,"active":true}

The XML version is roughly 2.5× longer for the same data. At scale — millions of API calls per day — this difference translates to meaningfully higher bandwidth consumption and parse time.

Parsing Complexity

Parsing XML correctly requires handling a significant specification: namespaces, DTDs, entity references, encoding declarations, mixed content, comments, processing instructions, and more. A conformant XML parser is a substantial piece of software. Errors in XML are fatal — a single malformed character breaks the entire document.

JSON parsing is straightforward by comparison. The grammar fits on one page. A conformant JSON parser can be written in a few hundred lines of code. Most programming languages have included native JSON support since the early 2010s.

Browser Integration

In browser-side JavaScript, JSON has a decisive advantage: JavaScript objects and JSON use the same syntax. A JSON string can be converted to a native JavaScript object with JSON.parse() and back with JSON.stringify(). Working with the resulting object uses standard JavaScript dot notation — no DOM traversal, no namespace handling, no XPath.

Working with XML in the browser required XMLDocument APIs — tree traversal, getElementsByTagName(), getAttribute() — that are significantly more verbose for the same operations.

The REST Shift

The architectural shift from SOAP to REST was the inflection point for JSON's dominance. SOAP is a protocol: it specifies not just the data format (XML) but the structure of messages, error handling, and service description (via WSDL). REST is an architectural style: it uses HTTP verbs and URLs without prescribing a data format.

REST APIs can use any format — XML, JSON, CSV, Protocol Buffers, or anything else. When developers built REST APIs without the constraint of SOAP's XML mandate, most chose JSON. By 2010, "REST API" was nearly synonymous with "JSON API." The programmable web had voted.

What XML Still Does Better

Despite JSON's dominance in APIs, XML retains genuine advantages in specific contexts:

• Document markup: XML can mix structured data with prose text — content can be both a data element and human-readable text. JSON has no concept of mixed content. HTML and XHTML are XML applications; JSON is not a document format.
• Schema validation: XML Schema (XSD) provides rich, standardised validation of XML documents — data types, constraints, element ordering, namespaces. JSON Schema (a separate, non-W3C specification) has matured significantly but is not yet as standardised as XSD.
• Transformation: XSLT allows XML documents to be transformed into other XML documents, HTML, or plain text using a declarative stylesheet language. JSON has no equivalent standard transformation language.
• Comments: XML supports comments (<!-- like this -->). JSON does not. For configuration files where human annotation is important, XML is more convenient than standard JSON.
• Namespaces: XML namespaces allow elements from different vocabularies to coexist in a single document. JSON has no equivalent concept.
• Attributes vs. elements: XML has both attributes and child elements, giving it two structural dimensions. JSON has only object properties — everything is a value of some key.

Enterprise and Government Persistence

XML has not disappeared. Enterprise systems built in the 2000s often used XML throughout and are difficult or expensive to change. Government and financial systems frequently use XML because the standards they comply with (HL7 for healthcare, ISO 20022 for financial messaging, XBRL for financial reporting) are XML-based and deeply embedded in regulatory frameworks.

In these contexts, XML's longevity is not conservatism — it is rational. The cost of migrating large, complex, regulated systems to JSON would be enormous, and the gain would be marginal for systems that are not facing the bandwidth and parse-time pressures of high-volume web APIs.

The Outcome

JSON won the web API format wars by being simpler, more browser-native, and adequately expressive for the structures most APIs need to convey. XML retained ground in domains where its richer feature set — mixed content, XSLT, XSD, namespaces — provides genuine advantages that JSON cannot match. Both formats are mature, well-specified, and well-supported; the choice between them is now a domain and use-case decision rather than a quality decision.

Format your JSON →