JSON vs XML: Which Data Format Should You Use?

Pick almost any greenfield API in 2026 and it will speak JSON. That makes "JSON vs XML" look like a settled argument — until you land on a project that integrates with a bank, a government service, a healthcare system, or a twelve-year-old internal SOAP endpoint, and suddenly XML is not a historical curiosity but the thing you have to work with today.

So this is a real comparison, not a victory lap. Below, the two formats go head-to-head on the dimensions that actually change a decision: verbosity, parse cost, expressiveness, validation, querying, and tooling. If you want JSON's own rules explained first, The Complete Guide to JSON covers the syntax end to end.

The same data, both ways

Start with an identical record so the differences are concrete.

{
  "order": {
    "id": "A-8842",
    "currency": "GBP",
    "total": 129.5,
    "items": [
      { "sku": "TSH-01", "qty": 2 },
      { "sku": "MUG-04", "qty": 1 }
    ]
  }
}

And the XML:

<order id="A-8842" currency="GBP">
  <total>129.50</total>
  <items>
    <item sku="TSH-01" qty="2"/>
    <item sku="MUG-04" qty="1"/>
  </items>
</order>

Two things jump out immediately, and they set up everything that follows.

First, XML has attributes. id and currency sit on the element rather than inside it. JSON has no such distinction — every piece of data is a member of an object, full stop. That is a simplification, and whether it is a loss depends on whether you were using the distinction meaningfully.

Second, XML has no arrays. <items> containing repeated <item> elements is a convention, not a language feature. A parser cannot tell from the document alone whether one <item> means a single-element list or a scalar. Every XML-to-JSON converter has to guess, and this is the single biggest source of conversion bugs.

Third, and less visible: in XML, 129.50 is a string. XML has no type system without a schema. In JSON, 129.5 is a number the moment it is parsed — and note it comes back as 129.5, because JSON numbers do not preserve trailing zeros. That is a real gotcha for money, and the standard answer is to send currency amounts as strings or integer minor units in both formats.

Round 1: Size on the wire

XML loses, consistently. Every field pays for a closing tag, so the tax scales with the number of fields rather than the amount of data. On typical records the equivalent XML runs 30-50% larger; on deeply nested documents with short field values it can be worse, because the tag names outweigh the content.

The usual counterargument is that gzip erases the difference, and it partly does — repeated tag names compress extremely well, often bringing the gap under 10%. But compression is not free, and it does not help with the next round.

Verdict: JSON, clearly, though gzip narrows it.

Round 2: Parse speed and memory

This is JSON's biggest structural win, and it is not really about size.

An XML parser has to handle namespaces, entity expansion, CDATA sections, processing instructions, attributes, and mixed content. DOM-based parsers then build a full node tree in memory, typically several times the size of the source document. Benchmarks vary by language and library, but a two-to-five-times speed advantage for JSON is the usual range, with a bigger gap on memory.

JSON parsers, by contrast, emit native language structures directly. JSON.parse in a browser is implemented in optimised C++ and produces objects you can use immediately — no DOM traversal, no type coercion pass.

XML can close some of this gap with streaming (SAX or StAX) parsers, and JSON has streaming parsers too. But at equivalent effort, JSON is faster.

Verdict: JSON, decisively.

Round 3: Expressiveness

Here XML wins on points, and it is worth being honest about why.

• Attributes vs elements let you separate metadata from content. <price currency="GBP">129.50</price> says something JSON needs an extra nesting level to express.
• Mixed content — text with elements interleaved, like <p>See the <em>full</em> report</p> — is native to XML and genuinely awkward in JSON. This is why documentation, publishing, and e-book formats are XML-based.
• Namespaces let two vocabularies coexist in one document without collisions. JSON has no equivalent; you rely on prefix conventions and hope.
• Comments exist in XML. JSON has none, which is why JSON config files are so often annotated in a README instead.

JSON's counter is that it has arrays and real types, and that most API payloads are data, not documents. That is true — but if your payload is a document, XML was designed for you.

Verdict: XML, for document-shaped data. JSON, for record-shaped data.

Round 4: Validation and contracts

XSD is old, thoroughly specified, and supported everywhere in the enterprise stack. It can express cardinality, value ranges, custom simple types, and cross-field constraints, and a partner can validate a message against it before sending. That maturity is the reason regulated industries stayed on XML.

JSON Schema does most of the same things and has improved sharply — draft 2020-12 is widely implemented, and OpenAPI's adoption of it means most API tooling now understands it. The gaps are practical rather than theoretical: multiple draft versions are still in circulation, error messages vary by implementation, and code generation is less uniform than XSD's.

Verdict: XML still ahead on maturity, JSON close enough for most new work.

Round 5: Querying and transformation

XPath and XSLT are powerful and standardised. XPath expressions can walk up the tree, filter on attributes, and use a large function library; XSLT can transform one document shape into another declaratively.

JSON's equivalents are JSONPath and tools like jq. JSONPath borrowed XPath's ideas and is excellent for extraction — it was only formally standardised as RFC 9535 in 2024, so implementations still differ in edge cases. There is no widely adopted declarative transformation language on the JSON side; people write code instead.

Verdict: XML, on standardisation. JSON's tooling is simpler but less uniform.

So which should you choose?

Choose JSON when: you are building a REST or GraphQL API, a browser or mobile client will consume it, payload size or latency matters, your data is records and collections, or you want the shortest path from wire format to native objects. This covers the overwhelming majority of new work.

Choose XML when: you are integrating with SOAP or WSDL services; you must conform to an industry standard such as ISO 20022, HL7 v2/v3, FpML, or ONIX; your content is prose with markup; you need digital signatures or encryption at the document level, where XML Signature and XML Encryption remain the mature options; or an existing XSD contract governs the integration.

The honest summary: JSON is the default and XML is the specialist. If you cannot name a specific reason you need XML, you do not need it.

Working across both

Most real projects end up handling both — a JSON-first service that has to talk to one XML partner. Conversion between them is routine, but treat it as lossy rather than automatic. When you convert, check three things: how single-element repeated tags are handled (does <item> become an object or a one-element array?), how attributes are represented (usually an @ or $ prefixed key), and whether numeric and boolean strings are being coerced when you did not ask for it.

For quick, one-off conversions the JSON to XML Converter and the XML to JSON Converter handle both directions in the browser, and pairing them with the XML Formatter makes the output readable enough to eyeball for exactly those gotchas. If the JSON side comes back as one unbroken line, formatting it first makes the comparison far easier, and a rejected conversion is usually a syntax problem on the input — our rundown of common JSON syntax errors covers what the parser is actually complaining about.

Because these tools run entirely client-side, you can paste a real SOAP envelope or a production API response into them without that payload leaving your machine — which is not something to take for granted when the document contains an account number or an auth token.