JSON vs XML: Why the Web Moved On, and Where XML Still Wins

By Andrew Butson · July 2, 2026 · 8 min read

XML and JSON are both plain-text ways of describing structured data, and for about a decade, the SOAP-and-enterprise-integration era of the early 2000s, XML was the default choice for almost everything: config files, API payloads, document formats, the works. JSON arrived in 2001, deliberately minimal, and by the mid-2010s had displaced XML as the standard shape for web APIs and app data. That's not because XML stopped working; it's because most day-to-day interchange never needed the machinery XML brings, and paying its verbosity tax for a simple key-value payload stopped making sense once a lighter alternative existed.

What's left is a fairly clean split: JSON for the wide, shallow world of REST APIs and application data, XML for the places that specifically need schemas, namespaces or document transformation, which turns out to still be a lot of enterprise software, and hiding inside more everyday files than most people realise.

Two generations of the same idea

XML and JSON both exist to answer the same question: how do you write structured data as plain text so any system can read it? But they were designed a full software generation apart, for different problems. The W3C standardised XML in 1998 to describe documents and data with maximum rigour: every document could declare its own vocabulary, validate itself against a schema, and be transformed by a standard toolchain. That rigour made it the backbone of enterprise integration and the SOAP web-services stack that dominated the early 2000s.

JSON showed up in 2001 as something much smaller: objects and arrays, a handful of value types, and nothing else, with no comments, no schema and no namespaces. Douglas Crockford's minimalism turned out to matter enormously once the web moved to REST APIs and JavaScript-heavy front ends, because JSON maps directly onto the data structures those languages already use. By the time ECMA-404 and RFC 8259 formalised it, JSON had already won the argument for most new web work, simply by being the lighter tool for a job that, most of the time, didn't need XML's full formality.

Verbosity: the price of self-description

XML's defining trait is that a document names its own data as it goes — every value sits inside an opening and closing tag that describes what it is, so a person can often understand a document just by reading it. The cost is that every tag name is written twice, once to open and once to close, and a deeply nested document accumulates that overhead at every level. A handful of fields in JSON might be a couple of lines of brackets and colons; the same fields in XML, with each one properly tagged, easily runs several times longer, for no gain in the information actually carried.

That overhead used to matter less when payloads were small and bandwidth was the scarcer resource being optimised for something else entirely. As APIs started shipping much larger, more frequent payloads to phones and browsers, the byte-for-byte cost of repeating every tag name became one of the concrete reasons teams moved to JSON, not because XML was wrong, but because the formality it charges for stopped being worth paying on every single request.

Attributes vs elements: XML's ambiguity, JSON's one way to write it

A subtler difference is that XML gives you two valid ways to attach the same piece of data to an element: as an attribute (<person id="1">) or as a nested child element (<person><id>1</id></person>), and the specification doesn't tell you which to prefer. Different schemas and different teams settle it differently, which is fine within one system but becomes a real problem the moment you convert XML to something else: a converter has to decide, case by case, whether an attribute becomes a JSON field like any other or gets treated specially, and whether mixed content (text sitting alongside child elements) has anywhere sensible to go in a format that has no equivalent concept at all. Morphr resolves this with a consistent mapping rather than losing the data, but the ambiguity is real and it lives in XML, not in the conversion.

JSON sidesteps the whole question by only offering one way to attach a value to an object: as a key. There's no attribute-versus-element decision to make and no schema-specific convention to learn, which is a large part of why JSON→JSON tooling never runs into the mapping ambiguities that XML conversions have to resolve by convention.

Where XML still rules

XML's remaining stronghold is exactly where its formality pays for itself: places that need to validate a document's shape before trusting it, transform it programmatically, or let multiple vocabularies share one document without clashing. An XSD schema can reject a malformed document before it's ever processed. JSON has no equivalent built into the format itself; JSON Schema exists, but it's a separate, optional specification layered on top rather than part of JSON proper. XPath and XSLT give XML a mature, standardised way to query and transform documents that JSON has never really matched. Enterprise integration and the older SOAP web-service stack still lean on all of this, as do large publishing and documentation pipelines that need guaranteed, validated structure.

XML is also hiding in plain sight far more than most people realise: modern Microsoft Office files, such as DOCX, XLSX and PPTX, and the OpenDocument formats (ODT, ODS, ODP) are, underneath their single-file appearance, ZIP archives of XML parts. Every time you save a Word document or an Excel workbook, you're writing XML; the file just doesn't look like it because the folder structure is zipped up into one icon. That's XML's staying power in a nutshell: not visible in a browser address bar anymore, but still the actual substance of an enormous amount of the world's day-to-day documents.

Frequently asked questions

Why did REST APIs move from XML (and SOAP) to JSON?

Mainly weight and fit. JSON is far less verbose for the same data, it maps directly onto the objects and arrays that JavaScript and most modern languages already use, and it dropped the schema-and-namespace machinery that SOAP-era XML relied on but most APIs never actually needed.

Does JSON have anything like an XML schema?

Not built into the format. XML has XSD as an integral, standardised part of its ecosystem; JSON's equivalent, JSON Schema, is a separate, optional specification that many tools support but that isn't part of the JSON standard (RFC 8259) itself.

Are Word and Excel files actually XML?

Yes. DOCX, XLSX and PPTX are Office Open XML, ZIP archives containing a set of XML files for the content, styles and structure, standardised as ISO/IEC 29500. Renaming one to .zip and unpacking it shows the XML directly. The OpenDocument formats (ODT, ODS, ODP) follow the same zipped-XML approach.

Can Morphr convert XML with attributes into JSON without losing data?

Yes. Morphr maps the element tree to equivalent JSON on your device, turning nested elements into objects and repeated elements into arrays. Attributes and mixed content have no exact JSON equivalent, since JSON only has one way to attach a value to an object, so they're mapped using a consistent convention rather than dropped.