JSON vs XML: Why Modern APIs Moved to JSON

JSON didn't win because XML was broken. It won because the web's dominant client shipped a JSON parser for free. By the mid-2000s, the typical API consumer was JavaScript running in a browser, and JSON.parseturned a response directly into objects, arrays, and primitives the calling code already understood. An XML response needed a DOM parser, then a separate walk over that DOM to extract values into the types the application actually wanted — a step JSON simply didn't require. That one structural fact, repeated across millions of API calls a day, is most of why json vs xml stopped being a real debate for REST APIs by the early 2010s.

The rest of this article is a comparison, not a takedown. XML is still the right choice in a few specific situations covered further down — this is a decision framework, not a verdict.

“XML is more verbose” is usually stated as an opinion. It doesn't need to be — the same record, expressed both ways, makes the difference concrete.

{
  "name": "Ada",
  "age": 34,
  "active": true,
  "skills": ["math", "engineering"]
}

<person>
  <name>Ada</name>
  <age>34</age>
  <active>true</active>
  <skills>
    <skill>math</skill>
    <skill>engineering</skill>
  </skills>
</person>

The JSON version is 87 bytes; the XML version is 155 bytes — nearly 80% larger for identical information. The gap is entirely structural: "name":"Ada" costs one colon and two quote pairs, while <name>Ada</name> repeats the word name twice. Every element in a document pays that tax, and it compounds with nesting depth — which is the core of the xml vs json performance argument at scale: more bytes over the wire, and more bytes for a parser to walk, on every single request.

The deeper issue with XML isn't just size — it's that XML has no native type system. Every value is text sitting between tags or inside an attribute. <age>34</age> is the three-character string 34until something — application code or an XSD — decides it should be parsed as a number. Get that step wrong and it's a silent bug: an age compared as a string, a boolean "false"that's truthy because it's a non-empty string.

JSON closes that gap by construction. Its grammar defines exactly six value types — string, number, boolean, null, array, object — and every mainstream language maps them onto its own native structures with no intermediate conversion step. JSON.parse in JavaScript, json.loadsin Python, and equivalents everywhere else hand back real numbers and real booleans, not text a caller has to re-interpret. That's the practical core of json vs xml apis: less code between “bytes received” and “typed value in hand,” and one less place for a type-casting bug to hide.

A fair comparison has to credit XML with what it genuinely does better, because these aren't marginal points.

• Namespaces. XML lets a single document safely mix elements from multiple schemas — <html:div> alongside <svg:rect> — without name collisions. JSON has no equivalent mechanism; two libraries that both want a top-level id key just collide.
• Schema validation maturity.XML Schema (XSD) predates JSON Schema by roughly a decade and is, in places, more expressive — complex type inheritance, substitution groups, and stricter content models than JSON Schema's allOf/oneOf composition currently offers.
• Mixed content.A paragraph with inline bold text and a link embedded in it is natural in XML's element model — text and markup interleave freely. JSON's strictly nested key-value model has no clean equivalent; you end up inventing a markup sublanguage inside a string, which is exactly what JSON was supposed to avoid needing.

None of this makes XML obsolete — it makes XML a format that won a narrower, still-important set of problems. SOAP-based enterprise integrations, common in banking, insurance, and government systems, are built entirely on XML envelopes and aren't being rewritten for a format change alone. Office document formats — DOCX, XLSX, ODF — are XML (zipped) under the hood, because mixed content and rich formatting are exactly the case XML handles well. And a chunk of the Java and broader enterprise ecosystem — Spring configuration, Maven's pom.xml, Android layout files — standardized on XML long before JSON was viable for configuration, and switching cost, not technical merit, is what keeps it there now.

Skip the abstract debate and match the format to the actual constraint.

• Building a new REST or GraphQL API?Use JSON. It's smaller on the wire, maps directly to native types in every mainstream language, and is what every modern HTTP client and tool expects by default.
• Integrating with an existing SOAP service or enterprise system?Use XML — not by choice, but because the wire format is dictated by the system you're talking to.
• Modeling documents with mixed text and inline markup?Use XML (or a markup format built on the same idea, like HTML). JSON's nested key-value model fights this use case rather than helping it.
• Need to validate incoming data against a schema?JSON Schema covers the vast majority of API validation needs; reach for XSD specifically when you need type inheritance or substitution groups JSON Schema doesn't model well.
• Writing configuration files by hand?Consider YAML over either — it's worth its own comparison, covered in JSON vs YAML.

Whichever format a payload arrives in, checking its structure by eye is the fastest way to catch a mistake before it reaches a parser. GenKitLab's JSON Formatter validates and pretty-prints JSON entirely in your browser, with line-and-column error reporting for anything malformed.