JSON vs XML vs YAML: Which One and When

XML is the oldest of the three. It wraps every value in named opening and closing tags and supports attributes, namespaces and comments. That richness makes it excellent for documents with mixed content and heavy metadata — think XHTML, SVG or SOAP web services. The cost is verbosity: the same data is typically 20–40% larger than the JSON equivalent, and the repeated closing tags make it noisier to read.

XML is not going away, because a great deal of infrastructure is built on it. Office documents, SVG graphics, RSS and Atom feeds, Android layouts, Maven builds and most SOAP endpoints are all XML, and each relies on features JSON simply does not have: attributes that annotate an element without becoming children, namespaces that let two vocabularies share one document, and mixed content where text and markup interleave inside a paragraph. If you are describing a document rather than a record, XML still earns its verbosity.

JSON strips the format down to data. There are no tags to close and no attributes to reason about — just objects, arrays and primitives. It parses natively in JavaScript and quickly in every other language, which is why it dominates REST and GraphQL APIs and the config files of countless tools. The trade-off is that plain JSON has no comments and no schema of its own, so documentation and validation live outside the file.

That minimalism also pushes work outward. There is no date type, so timestamps travel as ISO-8601 strings; no binary type, so files are base64-encoded and grow by a third; no reference mechanism, so a repeated sub-object is duplicated rather than pointed at. None of this is a defect — it is what keeps parsers small and predictable — but it does mean the contract between two systems lives in documentation and schemas rather than in the format itself.

For most machine-to-machine communication this is exactly what you want: minimal, unambiguous and fast. When a human needs to hand-edit the same data comfortably, YAML often steps in.

YAML is a superset of JSON designed to be pleasant to write by hand. It uses indentation instead of braces, allows comments, and drops most quotes — which is why it dominates CI pipelines, Kubernetes manifests and app configuration. The flip side is that its reliance on whitespace makes it error-prone: a stray space can change meaning, and its type-guessing occasionally surprises you. Many teams author in YAML and convert to JSON for machines to consume.

A useful mental model: XML for rich documents, JSON as the wire format between systems, YAML for files people edit. Since YAML is a JSON superset, any JSON document is already valid YAML — you can format and validate the JSON side of that pipeline here.

Raw byte size usually favours JSON. The same address book is typically 20 to 40 per cent smaller in JSON than in XML, because closing tags repeat every element name. Compression narrows the gap sharply — gzip and Brotli are very good at repeated tags — so over HTTP the practical difference is smaller than the raw numbers suggest. Where JSON keeps a real advantage is parse cost: its grammar has no entity resolution and no namespace machinery, so it is generally the fastest of the three to read.

YAML sits at the other end. Its grammar is by far the largest of the three, with anchors, aliases, multiple documents in one stream and several block-scalar styles, so YAML parsers are slower and heavier than JSON ones. For a configuration file read once at startup that cost is irrelevant. For a hot API path it is not, which is one more reason the authoring format and the wire format are often different things.

The absence of comments is JSON's most complained-about limitation. XML has them natively and YAML uses a hash prefix, but standard JSON has none, which is why config-heavy tools invented dialects: JSONC adds comments, and JSON5 adds comments, trailing commas, unquoted keys and single quotes. Both are convenient for hand-edited files, and both must be stripped before a strict parser sees them — so keep them out of anything you publish as application/json.

Validation is more even-handed. XML has DTD and XML Schema, JSON has JSON Schema, and YAML usually borrows JSON Schema because its data model is close enough. A practical pattern is to author configuration in YAML with comments, convert it to JSON during the build, then validate that JSON against a schema — giving you human-friendly editing and machine-checked structure from a single source.