JSON vs XML: What's the Difference and Which to Use?

The first API I ever owned spoke XML, and I once burned an entire afternoon certain the bug was in our parser. It wasn't. A partner had quietly wrapped one element in an XML namespace, so the wire now read <ns2:price> while our code was still hunting for <price>. Same number, same document, invisible difference — and that afternoon taught me more about the JSON-versus-XML question than any comparison table ever did.

Here's what I wish someone had told me that afternoon: these two aren't rival tools doing one job with different amounts of competence.

They were built for different jobs, and once you know which job you actually have, the choice mostly makes itself.

They were designed to solve different problems

XML arrived in 1998 out of SGML — the same lineage as HTML — and its purpose was to mark up documents. JSON showed up a few years later as Douglas Crockford's way to serialize a data structure straight out of JavaScript. That origin story explains almost every difference that follows.

Think of XML as a government form: labeled fields, an official structure, room for attributes in the margin and attachments stapled on. JSON is the sticky note that just has the three facts you needed. One is a filled-out document; the other is the data, and only the data.

Here's the same record in each. XML:

<user id="42">
  <name>Ada</name>
  <active>true</active>
</user>

And JSON:

{ "id": 42, "name": "Ada", "active": true }

Notice where id went. In XML it's an attribute; in JSON it's just another key, because JSON has no concept of attributes versus elements. That single missing distinction is why JSON code is shorter — and why converting between the two needs a rule for where attributes land.

Why JSON won the web API

JSON maps one-to-one onto the types your language already has: object, array, string, number, boolean, null. Parse a JSON response and you get a dictionary you can use immediately. Parse XML and you get a document tree you then have to interrogate — is this a child element, an attribute, a text node, a namespaced thing? — before you reach the value.

That difference in ceremony is the whole reason REST APIs drifted to JSON. Less glue code, fewer surprises, smaller payloads. When a response comes back as an unreadable single line, I run it through a JSON formatter to indent it, and if it's deeply nested I open it in a JSON viewer to click through the tree instead of counting brackets.

What XML still does better

Now the part the JSON crowd usually skips: XML isn't dead weight you're waiting to retire.

It handles mixed content — text interleaved with markup, like <p>Hello <b>world</b></p> — which JSON models only awkwardly. Its namespaces let you merge vocabularies from different sources without collisions (the exact feature that bit me, used correctly). And XSD schema validation plus XPath and XSLT give it a mature toolchain for enforcing and transforming document shapes. That's why DOCX, SVG, RSS, and SOAP are all XML under the hood, and why a lot of enterprise configuration still is too. JSON has grown its own answers — JSON Schema, JSONPath — but for document-shaped, heavily-validated content, XML's ecosystem runs deeper. If your real question is human-edited config rather than documents, that's a different fork: JSON vs YAML is the comparison you want.

Don't pick a religion — pick per payload

The honest truth is you rarely choose in a vacuum. The partner's API, the platform, the file format — something upstream usually decides for you, the way that namespaced <ns2:price> decided for me.

So the pragmatic move is to stop arguing and convert. Data outlives the notation it's written in; you can move a record from JSON to XML to satisfy a legacy endpoint, or turn an XML feed into JSON so your front end can treat it like any other object. It's the same lesson as what JSON actually is and the CSV and JSON conversion guide: the shape of your data matters more than the syntax you happen to store it in.

The one thing I'd tattoo on my younger self, mid-afternoon and blaming the parser: reach for JSON when programs are trading data, reach for XML when you're describing a document — and when something upstream has already chosen, just convert and move on.