XML dominated data interchange for the first decade of the 2000s. By 2020, JSON had won most new development. But XML hasn't gone away — it's still everywhere in enterprise systems, government APIs, and document formats. Here's when each one is still the right choice.

The same data in both formats

JSON:

{
  "customer": {
    "id": 42,
    "name": "Acme Corp",
    "orders": [
      { "id": 1001, "total": 99.99 },
      { "id": 1002, "total": 149.50 }
    ]
  }
}

XML:

<customer id="42">
  <name>Acme Corp</name>
  <orders>
    <order id="1001" total="99.99"/>
    <order id="1002" total="149.50"/>
  </orders>
</customer>

The XML version is longer, but it carries more semantic information per byte: element names appear as both opening and closing tags, making the structure self-documenting. Attributes attach metadata to elements without needing another nesting level.

Why JSON won

Brevity. JSON is typically 30-50% smaller than equivalent XML for the same data. Over high-volume APIs, that adds up to real bandwidth savings.

Native JavaScript support. When the web shifted to single-page apps and AJAX, JSON could be parsed with one line of JavaScript (JSON.parse). XML required either DOM parsing (verbose) or a third-party library. Developer ergonomics drove adoption.

Simpler data model. JSON has six types (string, number, boolean, null, array, object). XML has elements, attributes, text, CDATA, comments, processing instructions, namespaces, and DTDs. For most use cases, JSON's smaller surface area is a feature, not a bug.

Easier to generate. Most programming languages have built-in JSON serialization. Constructing XML by hand requires careful escaping of <, >, &, and quotes.

Where XML still wins

Document-centric data. XML was designed for marked-up documents — text with embedded structure. JSON struggles with this. An HTML-like document with embedded formatting tags is natural in XML but awkward in JSON.

Mixed content. XML can represent text with inline structural elements: <p>Hello <b>world</b>!</p>. JSON has no clean equivalent — you'd need an array of mixed strings and objects.

Schemas and validation. XML Schema (XSD) is mature, expressive, and battle-tested. JSON Schema is younger and less expressive (though improving rapidly). For complex validation rules, XML still has the edge.

Industry standards. Banking (ISO 20022), healthcare (HL7 v3, CDA), publishing (DocBook, DITA), and government (OASIS standards) overwhelmingly use XML. If you work in one of these industries, you'll see XML for years to come.

Office documents. Word (.docx), Excel (.xlsx), PowerPoint (.pptx), and OpenDocument formats are all XML internally. Any tooling that touches Office files works with XML.

RSS and Atom feeds. Blogging and podcasting still run on XML-based feed formats. JSON Feed exists but adoption is small.

SOAP and WS-* protocols. Enterprise web services from the 2000s use SOAP (XML-based). These services power core business processes at many large companies and aren't going away.

Performance comparison

Rough numbers for parsing a 1 MB document in JavaScript:

JSON is faster, but for documents under 100 KB the difference is imperceptible. Performance is only a deciding factor for high-throughput pipelines.

Converting between the two

The two formats have different data models, so conversion isn't lossless. Going JSON → XML: arrays of primitives are awkward in XML (each value needs an element name). Going XML → JSON: attributes don't map cleanly to JSON's flat key-value structure.

The most common convention for XML → JSON conversion treats attributes as JSON keys prefixed with @:

<user id="42" role="admin">Alice</user>
↓
{ "user": { "@id": "42", "@role": "admin", "#text": "Alice" } }

This convention is used by most XML-to-JSON libraries and our JSON ↔ XML converter. It round-trips cleanly: XML → JSON → XML produces a structurally equivalent document.

The verdict

For new projects: start with JSON unless you have a specific reason to use XML. The tooling, community resources, and library support are all stronger.

For integrating with existing systems: use whatever they use. Bridge formats at the boundary rather than trying to force conversion throughout your stack.

For document-centric data: XML is still better. JSON wasn't designed for marked-up text and shows it.

The two formats aren't replacing each other so much as settling into different niches. JSON for APIs, XML for documents and legacy enterprise systems. Both will be around for years.