The same data, two grammars
{"user": {"id": 1, "name": "Ada", "active": true}}
<user id="1"><name>Ada</name><active>true</active></user>
Same information, two structurally different representations — and the difference isn't cosmetic. JSON has six built-in types (including real booleans and numbers); XML has none — everything is text until something outside the document (a schema, or application code) says otherwise. That true in the XML example is just the three characters t, r, u, e to the XML parser itself; interpreting it as an actual boolean is up to whatever consumes the document.
Why JSON parses faster in practice
JSON's simpler grammar — no attributes, no namespaces, no distinct opening/closing tag matching for every single value — means a JSON parser generally does meaningfully less work per byte than an XML parser handling the equivalent data. This isn't just theoretical: JSON documents are also typically more compact for the same data (no repeated closing tag names, no attribute quoting overhead), meaning less data to parse in the first place. Combined, this is the practical reason JSON became the default for web APIs, where parsing happens on every single request.
What XML can do that JSON structurally can't
- Attributes —
<user id="1">attaches metadata to an element without it being a child value; JSON has no equivalent, so converters must invent a convention (like a@idkey) to represent the same idea. - Mixed content — text interspersed with child elements (
<p>Hello <b>world</b></p>), common in document-oriented markup; JSON's strict key-value/array model has no natural way to express this. - Namespaces — disambiguating identically-named elements from different vocabularies in one document; JSON has no built-in namespace mechanism.
- Mature schema/transform tooling — XSD for strict validation, XSLT for transforming one XML document into another — both considerably more mature and standardized than JSON's newer, less universally adopted equivalents (JSON Schema, JSONata).
Why XML persists despite JSON's popularity
Document-centric formats (RSS/Atom feeds, SOAP, many enterprise and government data interchange standards) rely on exactly the features JSON lacks — attributes, mixed content, strict schema validation — which is why XML hasn't disappeared, just receded to the domains where those features are actually needed rather than being used by default everywhere.
Common mistakes
- Assuming JSON is strictly "better" in every context. It's simpler and faster for typical API data, but it structurally cannot express what XML attributes, mixed content, and namespaces solve.
- Converting XML attributes to JSON without a clear convention, producing inconsistent results across different converters for the same source document.
- Choosing XML for a new API "for compatibility" without a specific reason, when the actual requirements (structured, non-document data) are exactly what JSON was designed for.
FAQ
Why is JSON generally faster to parse than XML?
Its simpler grammar (no attributes, no tag-matching overhead, more compact representation) means less work per byte for a parser, and the documents themselves tend to be smaller for equivalent data.
Can every XML document convert cleanly to JSON?
Not always — attributes and mixed content have no direct JSON equivalent, so a converter has to invent conventions, and different converters may resolve this differently.
Is XML obsolete now that JSON is more popular?
No — it remains the right choice for document-centric content, strict schema validation (XSD), and formats that specifically require namespaces or attributes, which JSON structurally cannot express.
Convert and validate JSON payloads with the JSON Toolkit — entirely client-side.