Comparison
XML vs JSON
JSON won the API era and XML still runs the documents. The difference that decides it is not verbosity — it is that JSON has no way to represent text interleaved with structure.
The usual argument is about syntax weight, and it is the least interesting difference. What actually decides the question is the data model. JSON has objects, arrays, strings, numbers, booleans and null. XML has elements, attributes, text, order, and text interleaved with elements — and three of those have no JSON equivalent at all.
That is why converting XML to JSON is lossy in ways a converter cannot warn you about. Run the same document through and you can watch it happen: the text around a child element is concatenated, two siblings with the same name become an array whose position no longer matches the document, and attributes end up as ordinary keys with a prefix.
None of that makes JSON worse. It makes JSON a data format and XML a document format, and picking the wrong one shows up months later as a field that cannot hold what it needs to.
What actually differs
| Aspect | XML | JSON |
|---|---|---|
| Data model | Elements, attributes, text, comments, processing instructions | Objects, arrays, strings, numbers, booleans, null |
| Mixed content | Native — text and elements interleave in order | No representation. Text either concatenates or moves to a key |
| Order | Document order is part of the data | Object keys are unordered; only arrays preserve position |
| Attributes | A separate axis from child elements | None. Conventionally flattened to prefixed keys |
| Schema | XSD, RELAX NG, Schematron, DTD | JSON Schema |
| Numbers | Text until a schema says otherwise, so "007" survives | IEEE 754 doubles, so 007 and large integers do not |
| Comments | Part of the specification | Not permitted |
Shown, not asserted
The differences above are claims, so here they are being made. Every one of these runs on each test run, against the same engines the tools use — the outputs are what came back, not what we expected.
Mixed content does not survive. The text around <b> is concatenated into one string, and its position relative to the element is gone.
document.xml <p>Some <b>bold</b> text.</p>What came back
json { "p": { "b": "bold", "#text": "Sometext." } }Document order goes with it. Two <a> elements either side of a <b> become one array, and the <b> floats out of position.
document.xml <r><a>1</a><b>2</b><a>3</a></r>What came back
json { "r": { "a": [ "1", "3" ], "b": "2" } }Attributes survive only by convention — here an @ prefix — and land beside the children rather than on their own axis.
document.xml <line sku="W-1" qty="2"><price>14.50</price></line>What came back
json { "line": { "price": "14.50", "@sku": "W-1", "@qty": "2" } }
Which to pick
XML, when
- The content is a document — prose with markup inside it, where the order of text and elements carries meaning.
- You need validation richer than shape checking: value patterns, cross-field rules, or a grammar someone else publishes.
- You are talking to something that already speaks it — a feed reader, a bank, a government portal, a SOAP endpoint.
- Identifiers must survive round-tripping. XML text stays text; JSON numbers do not.
JSON, when
- The payload is a data structure and the consumer is JavaScript, which is most web APIs.
- Payload size and parse speed matter more than expressiveness.
- Nobody will ever need to validate it against a grammar published by a third party.
- The team's tooling is JSON-first, and fighting that costs more than the fidelity is worth.
Where it reaches
- ToolsXML to JSON converterRun your own document through the converter these demonstrations use.
- ToolsXML to CSV converterThe other direction out of XML, when the data really is a table.
- FormatsSOAP envelopeThe format most often cited as the reason people left XML.
Related comparisons
- RSS vs AtomAtom is the better-specified format and RSS is the one everything reads. The real difference is strictness: Atom requires what RSS merely permits.
- Attributes vs child elementsThe oldest argument in XML, and the only parts of it that are not taste: attributes cannot repeat, cannot nest, and cannot be extended later.
Get started
Bring order to the XML your team can't afford to ignore.
Create a free account and get a private workspace to search, validate, diff, and monitor your XML feeds, sitemaps, schemas, and vendor integrations.