"JSON won" is the common shorthand for how this comparison gets summarized, and for the specific case of REST API payloads between a browser and a server, that's a fair conclusion. But treating XML as simply "JSON, but worse" misses real capabilities XML has that JSON was never designed to offer — which is exactly why XML hasn't actually disappeared from the systems that rely on those capabilities.
The Surface-Level Difference
<user id="1234">
<name>Alice</name>
<roles>
<role>admin</role>
<role>editor</role>
</roles>
</user>
{
"user": {
"id": 1234,
"name": "Alice",
"roles": ["admin", "editor"]
}
}
JSON is visibly more compact and maps directly onto data structures every mainstream language already has (objects, arrays, strings, numbers) — no translation step is needed to load it into a native data structure, which is a big part of why it became the default for web APIs. XML's verbosity buys real things in exchange, covered below — it isn't simply overhead with no purpose.
Attributes vs Elements: A Distinction JSON Doesn't Have
XML lets you attach data to a node two different ways — as an attribute (id="1234") or as a nested element (<id>1234</id>) — and this distinction, while it seems arbitrary at first, is genuinely useful for separating metadata about a piece of data from the data itself. JSON has no equivalent; everything is a key, flattening that distinction away. This matters more than it initially seems for documents where "data about the data" (an ID, a timestamp, a version marker) needs to be clearly separated from content — which is a meaningful part of why XML remains the format of choice for document-centric formats like SVG, DOCX, and EPUB (all XML-based under the hood), where content and structural metadata genuinely need to stay distinguishable.
Schema Validation Is a Real, Underrated XML Strength
XML has mature, first-class schema languages — XSD and the older DTD — that let you rigorously define and validate structure, data types, required fields, and even value constraints before any application code runs:
<xs:element name="age" type="xs:integer" />
<xs:element name="email">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="[^@]+@[^@]+" />
</xs:restriction>
</xs:simpleType>
</xs:element>
JSON's equivalent, JSON Schema, is genuinely good and widely used today — but it's a separate, bolted-on convention adopted by tooling, not something baked into the JSON specification itself the way XSD is baked into the XML ecosystem. In regulated industries (finance, healthcare, government data exchange) where strict, tooling-enforced structural validation is a compliance requirement rather than a nice-to-have, XML with XSD validation is often still the format of record for exactly this reason.
Namespaces: Solving a Problem JSON Doesn't Really Have
XML namespaces let documents from different vocabularies be combined without naming collisions — an RSS feed embedding both Atom and Dublin Core elements in the same document is a common real example:
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
<dc:creator>Alice</dc:creator>
</feed>
JSON has no equivalent mechanism, largely because the problem it solves — merging vocabularies from independent standards bodies into one document without key collisions — comes up far less in JSON's typical use case (a single API's own response shape) than in the document-interchange contexts XML was originally built for.
Where Each Format Actually Wins Today
JSON wins for REST/GraphQL APIs, config files, and anything consumed primarily by application code — the direct mapping to native data structures and lower parsing overhead are decisive advantages here, and there's little reason to choose XML for a new API today.
XML still wins for document formats needing rich structural metadata (SVG, DOCX, RSS/Atom feeds), systems requiring rigorous schema-enforced validation as part of a compliance process, and legacy enterprise integration (SOAP, many B2B EDI systems) where XML is the format the counterparty already speaks and switching isn't your call to make.
Converting Between Them
If you're working with a legacy XML API and need to eyeball its structure, or converting XML markup into something more compact to inspect, our XML Formatter pretty-prints and validates XML/HTML markup, and our JSON Formatter does the equivalent for JSON — useful for sanity-checking either format's structure before writing code against it.
Summary
- JSON's compactness and direct mapping to native data structures make it the right default for modern web APIs — this part of the "JSON won" narrative holds up.
- XML's attribute/element distinction and mature namespace support solve real problems document-centric formats still have, which is why SVG, DOCX, and RSS remain XML-based.
- XSD schema validation is a first-class part of the XML spec; JSON Schema is a widely-adopted but separate convention layered on top of JSON, not part of the format itself.
- Choose based on the actual consumer: application code parsing a REST response wants JSON; document interchange or compliance-driven structural validation is where XML still earns its verbosity.