JSON vs XML: what’s the difference, and when should you use each?

Guide · Updated July 2026 · ~8 min read

JSON and XML solve the same problem — representing structured data as text — with very different philosophies. JSON is a minimal notation for data structures; XML is a full markup language for documents. Knowing where each shines saves you from fighting your format later.

The same data, side by side

JSON                                XML

{                                   <user id="17">
  "id": 17,                           <name>Ana Ivanova</name>
  "name": "Ana Ivanova",              <active>true</active>
  "active": true,                     <roles>
  "roles": ["admin", "editor"]          <role>admin</role>
}                                        <role>editor</role>
                                      </roles>
                                    </user>

The JSON version is shorter and maps directly onto the arrays, objects, numbers, and booleans of every programming language. The XML version is more verbose but carries extra expressive machinery: attributes (id="17"), a named root element, and — not shown here — namespaces, comments, and mixed text-and-markup content.

The key differences

Where JSON wins

• Web APIs. JSON is the lingua franca of REST and most modern APIs. Every language parses it natively or with a tiny library, and it deserializes straight into the data structures you already use.
• Configuration for developer tools. package.json,tsconfig.json, and countless others — though the lack of comments hurts here, which is why variants like JSONC exist (see ourJSON syntax guide).
• Anything read by JavaScript. In the browser, JSON is effectively free.

Where XML wins

• Documents with mixed content. A paragraph where text, emphasis, and links interleave — <p>See <a href="…">this</a> page</p> — is natural in XML and awkward to the point of uselessness in JSON. This is why HTML, SVG, and DocBook are markup languages, not object notations.
• Industry standards and enterprise integration. SOAP, RSS/Atom feeds, XBRL financial reports, HL7 healthcare messages, Android layouts, Maven builds — decades of infrastructure speak XML, with mature schema validation (XSD) and transformation (XSLT) tooling.
• Strict contracts. When two organizations exchange data and both sides must validate structure, types, and constraints, XSD is still the most battle-tested option.

Size and speed, in practice

XML’s verbosity is real but frequently overstated, because the thing that makes it verbose — repeating every element name in the closing tag — is also the thing compression algorithms handle best. For a typical record-shaped payload:

Since essentially every HTTP server compresses responses, the practical difference on the wire is far smaller than the raw numbers suggest. Where JSON’s advantage stays decisive is parsing in JavaScript: JSON.parse() is implemented in native code and is dramatically faster than building a DOM from XML. If you are choosing a format for a browser-facing API, that — not byte count — is the argument that matters.

Neither one: the rest of the landscape

JSON and XML are not the only options, and sometimes the reason you are unhappy with both is that the job belongs to a third format:

• YAML — a superset of JSON with comments, references, and far less punctuation. Dominant for configuration you edit by hand (Kubernetes, CI pipelines, Docker Compose). The cost is significant whitespace and a surprisingly large specification, which makes it error-prone in exactly the way indentation-sensitive formats always are.
• TOML — designed for configuration and nothing else, with obvious semantics and no ambiguity. Used by Rust’s Cargo.toml and Python’s pyproject.toml. Weak at deep nesting, which is deliberate.
• Protocol Buffers, Avro, MessagePack — binary formats with schemas. Much smaller and faster than either text format and not human-readable at all. The right answer for high-volume service-to-service traffic, the wrong answer for anything a person needs to inspect.
• CSV — still unbeaten for flat tabular data. If your JSON is an array of objects that all have the same keys, CSV is smaller, streams naturally, and opens in a spreadsheet.

A useful rule: pick the format by who reads it. Humans editing by hand favour YAML or TOML, programs exchanging data over HTTP favour JSON, documents with markup need XML, and machines talking to machines at volume want something binary.

Common misconceptions

“XML is obsolete.” It has lost the web-API war, but it remains everywhere: every RSS feed, every SVG image, every Android app resource, most enterprise message buses. You will read and debug XML for decades to come.

“JSON is always smaller and faster.” Usually, but not inherently — gzip compresses XML’s repetitive tags very well, and a SAX-style streaming XML parser can beat loading a giant JSON blob into memory. For typical API payloads, though, JSON is leaner.

“You can convert losslessly between them.” Only approximately. XML attributes, namespaces, comments, and mixed content have no JSON equivalent, and JSON’s types are lost when everything becomes XML text. Our guide toJSON ⇄ XML conversion covers the pitfalls in detail.

The bottom line

Choose JSON for APIs, configs, and program-to-program data — it’s smaller, simpler, and native to the web. Choose XML for document markup, mixed content, or when an existing standard or schema-validated contract demands it. Most working developers deal with both every week — which is exactly why Indentio’sJSON and XML tools live in the same editor, with a converter between them.

Keep reading