JSON vs XML

Origins: a markup language versus a data format

XML's ancestor is SGML, and its design goal was marking up documents: prose that mixes paragraphs, emphasis and structure. That is why XML alone of the two supports mixed content — text with inline markup like <title>Learning <em>XML</em></title> — and why it grew attributes, entity references and a heavyweight processing model. JSON was extracted from JavaScript object literals around 2001 for exactly one purpose: moving structured data between programs with the least possible grammar. There is no mixed content in JSON, no entity machinery, and no document tree — objects, arrays and four scalar types are the entire universe.

Syntax: the tag tax, attributes and the missing array

Every XML element opens and closes, so a simple value costs two tags: <price>19.99</price>. XML offers an alternative spelling — <price currency="EUR">19.99</price> — and the attribute-versus-element choice has generated debate for two decades without a universal answer. JSON has exactly one spelling for a key/value pair and one for a list. Crucially, JSON has native arrays; XML has no array type at all. A list is expressed by repeating an element, which means every JSON-to-XML tool must agree on a convention for naming and wrapping repeated items.

Schemas and namespaces: where XML still earns its keep

XSD is XML's quiet advantage in enterprises: a mature schema language with derived types, cardinality constraints, pattern facets and two decades of tooling that can validate a document and report precisely which element broke which rule. JSON Schema pursues the same goal with a different shape — it is expressive, supports conditional logic, and has become the de facto contract language for modern APIs — but its long draft history means tooling varies more in what it accepts. Both ecosystems can be strict; XML's is simply older.

Namespaces are XML's other enduring feature. An XHTML page can embed SVG and MathML without key collisions because each vocabulary carries its own URI. JSON has no equivalent mechanism — name collisions are avoided by convention, or by layered designs such as JSON-LD that attach context explicitly.

Size, streaming and when to pick which

For the same data, XML payloads are usually larger: closing tags alone roughly double the element markup, and attribute-heavy styles add more. Both formats compress well with gzip — XML's redundancy is highly compressible — but the base overhead rarely closes completely. On streaming, XML's parser ecosystem runs deeper: SAX and StAX push parsers were designed for documents too big for memory, and every platform ships one. JSON streaming parsers exist and are excellent, but whole-document parsing remains the common default.

Pick JSON for anything a pair of programs exchanges: web and mobile APIs, structured logs, service-to-service payloads. Pick XML when a specification mandates it — SOAP stacks, publishing pipelines, Office formats, many healthcare and finance standards — or when you need XSD validation and namespaces on the wire. The guidance reverses cleanly: JSON leaking into a document pipeline usually wants to be XML, and a SOAP-era API exposing clean JSON is a migration win, not a betrayal.