JSON vs XML: Which Should You Use?

{
  "user": {
    "id": 42,
    "name": "Ada Lovelace",
    "active": true,
    "languages": ["English", "French"]
  }
}

And in XML:

<user id="42">
  <name>Ada Lovelace</name>
  <active>true</active>
  <languages>
    <language>English</language>
    <language>French</language>
  </languages>
</user>

Three differences are visible immediately, and they run deeper than they look.

XML has two places to put things. id is an attribute; name is an element. Nothing tells you which a given piece of data should be — it is a modelling decision, and reasonable people make it differently, which is why the same data appears in two shapes across two APIs. JSON has one place: a member of an object.

Types are JSON's, not XML's. In the JSON, 42 is a number and true is a boolean, and a parser gives you them as such. In the XML both are text, and something further down has to know that active should be interpreted as a boolean. XML gets types from a schema, or not at all.

XML repeats itself. Every element names itself twice. On small payloads this hardly matters; on a large array of records it is roughly double the bytes for the same information, before compression.

Not, mostly, because it is prettier. Three practical reasons, in order of how much they mattered.

It arrives as objects. A JSON response parses into the native data structures of whatever language received it, in one call. XML parses into a document tree that you then have to walk — getElementsByTagName, node lists, text nodes, the distinction between an element and its content. For the common case of "give me these five fields", that is a great deal of ceremony for no benefit.

The model matches the data. Most API payloads are records: named fields with values, and lists of those. JSON's objects and arrays are exactly that. XML's elements-plus-attributes model is designed for marked-up text, and using it for records means either choosing arbitrarily between attributes and child elements, or picking one convention and defending it forever.

It was already in the browser. As the web moved to client-rendered applications, the format that needed no library and no traversal API on the client was going to win regardless of its merits. SOAP's decline took a lot of XML tooling with it.

The size difference is real but usually overstated. XML is typically 1.5–2× the bytes of the equivalent JSON, and both compress extremely well because both are repetitive text. Once gzip or Brotli is in the path, verbosity is closer to a readability issue than a bandwidth one.

Any comparison that stops at "JSON is better" is not describing the world. These are genuine capabilities with no JSON equivalent.

Validation is part of the specification. The XML recommendation defines two distinct standards: a document is well-formed if it obeys the syntax, and valid if it "has an associated document type declaration and if the document complies with the constraints expressed in it". That distinction is built in, along with validating and non-validating processors. JSON has no equivalent in its specification at all — JSON Schema is a separate standard that you must adopt and enforce yourself, and most projects do neither.

Mixed content. Text with markup inside it — a paragraph containing a link and an emphasised phrase — is what XML was built for and what JSON models worst. Every JSON representation of a rich document ends up either as an HTML string inside a field, which gives up all structure, or as an elaborate node tree that reimplements XML badly.

Namespaces. XML can combine vocabularies from different sources in one document without name collisions. JSON's answer is convention: prefixed keys, and hope. This matters much more than it sounds when documents are assembled from multiple systems.

Transformation as a standard. XSLT transforms one XML document into another declaratively. The JSON equivalent is writing code. For pipelines where the transformation is the product — publishing, financial messaging — that is a real difference.

Add comments to the list, which JSON also lacks, and the pattern is clear: XML's extra machinery is the cost of capabilities that document-oriented work genuinely needs.

Not legacy systems — current, deliberate choices:

Documents rather than records. DOCX, ODF and EPUB are XML underneath. So is SVG. When the content is marked-up text, XML is not the compromise.

Regulated industries with mandated schemas. Financial messaging (ISO 20022), healthcare (HL7 CDA), government filings, tax and legal submissions. The schema is the contract, validation is the enforcement, and there is no JSON pathway.

Publishing pipelines. Where XSLT and XPath are doing real work and would need reimplementing as code.

Feeds. RSS and Atom are XML and are not going anywhere.

Configuration in some ecosystems. Maven and older .NET tooling, where the surrounding tooling assumes it.

If you are building a new HTTP API in 2026, JSON is the default and choosing XML needs a reason. If you are exchanging documents with a party who has published a schema, XML is the default and choosing JSON needs their agreement.

XML to JSON is lossy in a way that surprises people, because the two models do not correspond.

Attributes are the crux. XML distinguishes <user id="42"> from <user><id>42</id></user>; JSON has one kind of member, so a converter must invent a convention. ToolForge's converter prefixes attributes with @ and puts element text under #text, which is a common approach and makes the original distinction recoverable:

{ "user": { "@id": "42", "name": { "#text": "Ada Lovelace" } } }

Four other things do not survive cleanly:

Types. Everything in XML is text, so 42 converts to the string "42" unless the converter guesses — and guessing turns a phone number with a leading zero into a mangled integer. Not guessing is the safer default.

Repeated elements. One <language> child converts to an object; two convert to an array. A consumer that expected an array gets an object when the data happened to have a single item, which is one of the most common bugs in XML-to-JSON pipelines. Handle both shapes.

Namespaces. A prefix like ns2:element becomes part of the key name, so the namespace's meaning is gone even though the text survives.

Comments, CDATA and processing instructions. Dropped entirely; JSON has nowhere to put them.

Going the other way, JSON to XML, is mechanically easier but requires you to invent element names for array items — since JSON arrays are unnamed — which means the round trip does not return the document you started with.