XML vs JSON
XML vs JSON: verbosity, schema validation, and why JSON won the API war but XML never really left.
Last updated
The short answer
JSON is lighter, maps directly onto objects and arrays in most programming languages, and is the default for new APIs. XML still earns its place where you need document-oriented features JSON doesn't have — namespaces, mixed content, mature schema tooling (XSD) — which is why it persists in enterprise, SOAP and document formats long after losing the API popularity contest.
| Dimension | XML | JSON |
|---|---|---|
| Verbosity | Heavier — opening and closing tags | Lighter — braces and brackets |
| Attributes | Supports attributes and mixed content | No native attribute concept |
| Schema validation | Mature (XSD, DTD, RelaxNG) | JSON Schema exists, less universal |
| Data types | Everything is text unless schema says otherwise | Native numbers, booleans, null, arrays |
| Namespaces | Built in — mixes vocabularies safely | No equivalent concept |
| Parsing in JS | Needs a DOM parser | JSON.parse(), native |
Choose XML when
- →You're working with a format or protocol that already mandates it — SOAP, RSS/Atom feeds, Office document formats, many enterprise systems.
- →You need namespaces to combine vocabularies from different sources in one document without name collisions.
- →You need mixed content — text interleaved with markup, like a paragraph containing inline emphasis — something JSON can't express.
Choose JSON when
- →You're designing a new API — JSON is the de facto default and every mainstream language parses it natively.
- →You want the payload to map directly onto objects and arrays without an intermediate DOM-walking step.
- →You want a human to read and hand-edit a small payload without wading through closing tags.
The catch nobody mentions
JSON has no native way to represent metadata about a value — XML attributes and namespaces exist precisely because 'is this a comment or content, and whose vocabulary is it from' matters in document-shaped data. Reaching for JSON in a domain that actually needs those features usually means reinventing them badly with ad-hoc conventions ($ref, @type prefixes) instead of using the format built for it.
Questions
Is XML obsolete?
No, it is entrenched where it already won — SOAP services, document formats such as DOCX and SVG, publishing pipelines, and enterprise integration. It is rarely the choice for a new web API, which is a different statement.
What does XML offer that JSON does not?
Attributes alongside elements, namespaces, comments, a mature schema language, and XPath for querying. Those matter for documents with mixed content and formal contracts, and are overhead for a payload of key-value pairs.
Is parsing XML a security risk?
It can be. XML external entity processing lets a document reference local files or internal URLs, which has been a serious vulnerability class for years. Disable external entities on any parser reading untrusted input.
Why is JSON smaller?
No closing tags and less structural markup, so the same data typically takes noticeably fewer bytes. The gap narrows considerably once both are compressed, which is how they actually travel.
Does JSON have a schema language?
JSON Schema, which is widely supported and does the job. It arrived later and is less formally rigorous than XML Schema, which occasionally matters and usually does not.
How should I convert between them?
Carefully, because the models do not map cleanly — XML attributes, mixed content and repeated elements all need conventions in JSON. Any automatic conversion makes choices for you, so check them against real documents rather than one sample.