JSON vs XML

JSON is a serialisation of the data structures a program already has: objects, arrays, strings, numbers, booleans, null. Parse one and you get back the shape you put in, which is why it took over web APIs — there is nothing to map, and every language reads it into native types with one call.

XML came from the publishing world and models a document: a tree of elements with attributes, mixed content, and text that can contain markup inside it. It can express a paragraph with a bold word in the middle of it, which JSON cannot do without inventing a convention. Both are text and both are hierarchical, and they were designed to describe different kinds of thing.

It is smaller, because element names are not repeated at the end of every value. It is faster to parse, meaningfully so at volume. It maps directly onto the objects a program is going to use. And it is trivially readable in a browser’s developer tools, which mattered more than anything else during the years the decision was being made.

The corresponding loss was tooling. XML arrived with schema validation, namespaces, transformation and a query language, all standardised and all mature. JSON has equivalents now — JSON Schema, JSON Pointer, JSONPath — but they arrived later and are less uniformly supported, which is a real cost in the places where that machinery is the point.

Documents, first: EPUB, DOCX, XLSX, ODT and SVG are all XML underneath, because the thing being described is a document and no other format models mixed content sensibly.

Then regulated exchange. Healthcare, finance, government, insurance, law and publishing all run on XML standards with schemas that define exactly what a valid message contains — HL7, XBRL, various tax and customs filings, MARC. In those settings validation is not overhead, it is the contract, and a validating parser rejecting a malformed document before a system reads it is the whole point.

And configuration for tooling built in that era — Maven, Ant, Android layouts, .NET project files — where the ecosystem is settled and rewriting it would buy nothing.

Comments. The specification has none, which is why every configuration format built on JSON has either invented them or been abandoned. It is the single most common complaint and it is the reason JSON is a poor configuration language, whatever its merits as a wire format.

Dates. There is no date type, so everyone agrees to use ISO 8601 strings and every parser hands you a string. Trailing commas are forbidden, which makes hand-editing a list irritating. And there is only one number type, which means large integers lose precision in JavaScript — an identifier past about 9 quadrillion silently changes value, and financial and database systems really do hit this.

The attribute-or-element question, which has no correct answer and which every team argues about. Namespaces, which are genuinely necessary for combining vocabularies and are the largest single source of parsing bugs. Whitespace handling, which is subtle and inconsistent between parsers.

And a security concern with no counterpart in JSON: XML parsers historically expanded external entities, allowing a document to read local files or make network requests from inside the parser. It has caused real breaches, and while modern parsers disable it by default, any XML input from an untrusted source deserves the check.

There is no way to annotate a JSON file. Douglas Crockford, who specified the format, removed comments on purpose after seeing them used to carry parsing directives — turning a data format into something each tool interpreted slightly differently.

The consequence is felt by anyone who has tried to document a configuration file. The usual workarounds are a `_comment` key that every consumer must agree to ignore, or a format built on JSON that adds them back. XML has had comments from the beginning, which is a small reason it is still preferred where a human is expected to edit the file by hand.

JSON has one numeric type and no statement about how it is stored. In practice nearly every parser reads numbers into a 64-bit float, which represents whole numbers exactly only up to about nine quadrillion — two to the fifty-third.

Beyond that, digits are quietly lost. A 64-bit database identifier or a Twitter-style snowflake ID passed through JSON as a number can come out changed in its last few digits, and nothing anywhere reports an error. The standard fix is to send such identifiers as strings, which is why so many APIs return `"id": "7213..."` in quotes for something that is plainly a number.

JSON has strings, numbers, booleans, arrays, objects and null. There is no date. Every date in every JSON document is a string or a number by convention, and the convention that won is ISO 8601 — `2026-08-08T14:30:00Z` — because it sorts correctly as text and cannot be read as day-first or month-first by mistake.

XML on its own is no better, but XML Schema adds real types including `xs:date` and `xs:dateTime`, and a validating parser will reject a malformed one before your code sees it. That is the shape of the whole comparison in miniature: JSON leaves agreement to the two ends of the pipe, XML offers to enforce it and charges for the machinery.

JSON to XML is mechanical and produces something usable: objects become elements, arrays become repeated elements, values become text. Two things do not survive the trip. A key that is not a legal element name has to be renamed — `1`, `a b` and the empty string are all valid JSON keys and XML forbids every one of them — and type goes with it, because the number 1 and the string "1" arrive as the same element text.

XML to JSON is where the approximation lives, and the culprits are attributes and mixed content. An attribute has to be given a made-up key name, so most converters prefix it with an at sign or fold it into the object; a paragraph with markup inside it has no JSON representation at all and comes out as a string with tags in it, or as an array that has lost the ordering. For data-shaped XML the conversion is clean; for document-shaped XML it is a downgrade, and the round trip does not come back the same.

An API, a configuration file consumed by a program, a message queue, a data export, anything a JavaScript front end will read: JSON. It is the default and the burden of proof is on anything else.

A document format, a standard somebody else defined, an exchange where a schema has to be enforced, or an ecosystem already built on XML: XML, without apology. And for configuration a human will edit, neither — TOML or YAML exist because JSON has no comments and XML is too verbose to read comfortably, and that is a narrow enough need to deserve its own format.