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. The example above uses fewer characters in JSON. The difference depends on field names, data shape, whitespace and compression; measure your actual payload.

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

Compare the UTF-8 byte lengths of equivalent documents before and after compression. Then measure parsing in your target runtime.

RFC 8259 and the XML specification define the formats, but neither gives a universal size or speed ratio.

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. Many parsers, including Java's built in ones, still allow them by default, so turn them off explicitly.

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

Situation | Use

New web or mobile API | JSON

Configuration files | JSON or YAML

Rich text documents, publishing | XML

Integrating with SOAP or enterprise systems | XML, because they require it

Data with strict schema and namespaces | Either, XML has the edge

Logs and event streams | JSON, one object per line

Most of the time, JSON.

Use our JSON formatter to pretty print and validate a document in your browser. The JSON visualizer draws its nested structure as a diagram.