XML vs JSON: Why Modern APIs Chose JSON (And What to Do With Legacy XML)

XML had a decade of dominance. SOAP services, RSS feeds, WSDL definitions, XML-RPC, Atom — the 2000s were the XML era. Then JSON showed up and, within five years, had displaced XML in virtually every new API design.

This shift wasn't an accident. Understanding why it happened explains how to think about XML in 2026 — and what to do when you're still stuck with it.

Why XML Won (Initially)

In the late 1990s, XML was the right solution to a real problem: how do you exchange structured data between heterogeneous systems in a standardised, self-describing, extensible way?

XML's advantages over what came before:

- **Self-describing** — tag names carry semantic meaning, unlike CSV column indices

- **Schema validation** — DTD and later XSD allowed strict contract enforcement

- **Namespaces** — multiple vocabularies could coexist in one document

- **Mature tooling** — XSLT, XPath, XQuery, SAX, DOM parsers were robust and well-supported

- **Enterprise buy-in** — IBM, Microsoft, and Sun had all committed to XML-based integration

SOAP built on top of XML gave enterprises type-safe, contract-driven, WS-* compliant web services. It was verbose, but it worked at scale and had tooling for generating client code from WSDL definitions.

Why JSON Won

JSON emerged from JavaScript, specifically from the observation that JavaScript's native object syntax was a perfectly good data interchange format — small, readable, and directly parseable by browsers without a library.

The decisive advantages:

- **No parser required** in JavaScript — JSON.parse() was everywhere

- **One-third the size** of equivalent SOAP/XML payloads

- **No schema required** — for early REST APIs, flexibility was a selling point

- **Ajax compatibility** — JSON responses from REST APIs were trivial to handle in browser JavaScript

- **Readability** — developers could read JSON in network inspector panels; SOAP XML required a formatter just to see the structure

The REST + JSON combination spread from Web 2.0 companies (Twitter, Flickr, Stripe, GitHub) and became the default for every new API. By 2015, "REST API" meant JSON, implicitly.

Where XML Still Lives in 2026

XML was not eliminated — it retreated to specific domains:

**Enterprise integration.** EDI (Electronic Data Interchange), financial messaging (ISO 20022, SWIFT), healthcare (HL7, FHIR in some implementations), and insurance systems run on XML. These industries have decade-long data contracts and migration is expensive.

**SOAP services.** Banking, telecoms, and government APIs frequently still use SOAP. Any developer integrating with an older enterprise system hits SOAP XML.

**Document formats.** Microsoft Office (DOCX, XLSX, PPTX), OpenDocument, SVG, EPUB — all XML-based. This isn't going away because the format serves documents, not data interchange.

**RSS and Atom feeds.** Podcast feeds, news feeds, and content syndication remain XML. The format is stable and decades of tooling support it.

**Android resources.** Layout files, string resources, manifest — Android's build system is XML-based. React Native and Flutter have displaced native XML layouts somewhat, but XML is still part of the Android ecosystem.

**Maven and Spring.** Java's Maven build tool uses pom.xml; Spring configuration uses XML (though annotations have largely replaced it). Older Java systems are heavily XML.

Working With Legacy XML in Modern Applications

Three patterns for handling XML at the boundary of a modern system:

**Convert at ingestion.** When pulling data from a SOAP or XML API, convert immediately to JSON at the integration layer. Store JSON internally, process JSON throughout the application, never pass XML beyond the adapter. This is the cleanest pattern but requires building an XML → JSON adapter.

**Use an XML parsing library.** For deep integration where XML schema matters (namespaces, attributes, CDATA, mixed content), use a proper XML library rather than a converter. Python's lxml, Ruby's Nokogiri, Java's JAXB, and JavaScript's fast-xml-parser handle XML correctly in ways a generic converter might not.

**Keep XML natively.** PostgreSQL's xml type and MySQL's XML functions can store and query XML natively. If your source systems produce XML and your queries are simple, storing XML and querying with XPath might be simpler than converting.

The Structural Difference

The deepest difference between XML and JSON isn't syntax — it's the data model.

JSON has objects, arrays, strings, numbers, booleans, and null. That's it.

XML has elements, attributes, text nodes, CDATA sections, namespaces, processing instructions, and comments. The same data can be modelled multiple ways:

<user id="1">Alice</user>

<user><id>1</id><name>Alice</name></user>

<user id="1" name="Alice" />

These three XML fragments express similar data differently. Converting XML to JSON requires making choices about how to represent attributes, text nodes, and mixed content. Different converters make different choices — which is why XML-to-JSON conversion results vary between tools.

Understanding what your specific XML structure needs to become in JSON is as important as the conversion itself.