JSON vs XML: Which Data Format Should You Use?

JSON replaced XML as the default web data format more than a decade ago, but XML has not gone away. It still runs a large share of enterprise integration, document formats and configuration in the Java world. Choosing between them is easy once you know what each one is good at.

The same data in both

{
  "book": {
    "id": 42,
    "title": "Refactoring",
    "authors": ["Martin Fowler", "Kent Beck"],
    "inPrint": true
  }
}

<book id="42">
  <title>Refactoring</title>
  <authors>
    <author>Martin Fowler</author>
    <author>Kent Beck</author>
  </authors>
  <inPrint>true</inPrint>
</book>

Two things jump out. The XML is longer because every element name is written twice. And the XML has a choice JSON does not: id could be an attribute or a child element, and different people will choose differently.

Where JSON wins

• Size. JSON is typically 30 to 50 percent smaller for the same data. Over millions of API calls that is real bandwidth.
• Maps directly onto data structures. Objects become dictionaries and arrays become lists in every language. XML needs a mapping layer to decide what becomes an attribute, an element or text.
• Native types. JSON distinguishes the number 42 from the string "42" and has real booleans. In XML everything is text until a schema says otherwise.
• Arrays. JSON has them. XML fakes them with repeated elements, and a list with one item is ambiguous without a schema.
• Parsing in the browser. JSON.parse is built in and fast. XML parsing in JavaScript is clumsy.

Where XML wins

• Documents with mixed content. Text with markup inside it, like a paragraph containing bold words and links, is natural in XML and awkward in JSON. HTML itself is XML shaped for this reason.
• Mature schema and validation. XSD and Relax NG have been standard for twenty years. JSON Schema exists and works well, covered in our JSON Schema introduction, but XML validation tooling in enterprise stacks is deeper.
• Namespaces. XML can combine vocabularies from different sources in one document without key collisions. JSON has no equivalent.
• Transformation. XSLT can turn one XML document into another declaratively. There is no standard JSON equivalent, though jq comes close for many tasks.
• Comments and metadata. XML allows comments and processing instructions. JSON has neither.
• Existing standards. SOAP, SAML, RSS, SVG, Office documents, Android layouts and Maven all use XML and are not changing.

Size and speed in practice

For a typical API payload, JSON is smaller before compression and parses faster in every mainstream runtime. After gzip the size gap narrows a lot because XML's repeated tags compress well. If your payloads are compressed, choose on developer ergonomics rather than bytes.

Security notes

XML parsers have a history of vulnerabilities such as external entity expansion and billion laughs attacks, because the format supports entity definitions that reference other content. Modern parsers disable these by default but you must check. JSON parsers have a much smaller attack surface. The main JSON risk is precision loss on very large numbers, which we cover in JSON.stringify and JSON.parse Explained.

Recommendation

Most of the time, JSON. When you do need to inspect one, our JSON formatter will pretty print and validate it in your browser.