JSON vs XML vs YAML: Which Data Format Should You Use?

JSON, XML and YAML all represent structured data, but they’re optimised for different jobs. Here’s the same data in each format, followed by an honest comparison.

The same data, three ways

JSON

{
  "user": {
    "name": "Ada",
    "roles": ["admin", "editor"],
    "active": true
  }
}

XML

<user>
  <name>Ada</name>
  <roles>
    <role>admin</role>
    <role>editor</role>
  </roles>
  <active>true</active>
</user>

YAML

user:
  name: Ada
  roles:
    - admin
    - editor
  active: true

Side-by-side comparison

	JSON	XML	YAML
Readability	Good	Verbose	Excellent
Size	Compact	Largest	Compact
Comments	No	Yes	Yes
Native data types	String, number, boolean, null, array, object	Everything is text (types via schema)	Rich, sometimes surprising
Whitespace-sensitive	No	No	Yes (indentation)
Schema / validation	JSON Schema	XSD, DTD (mature)	JSON Schema (often)
Parsing speed	Very fast	Slower	Slower
Typical use	APIs, web apps, NoSQL	Documents, enterprise, SOAP, RSS, SVG, Office files	Config files, CI/CD, Kubernetes

JSON: the web’s default

Strengths: simple, strict and unambiguous; parsed natively by every browser and language; compact and fast.

Weaknesses: no comments; no date type; a single syntax slip breaks the document; strict quoting gets tedious for hand-edited config.

Choose JSON for: REST and GraphQL APIs, data exchange between services, browser storage, NoSQL documents. Format and validate it with the JSON formatter.

XML: documents and enterprise systems

Strengths: handles mixed content (text with inline markup) better than any alternative; attributes and namespaces; mature schema and transformation tools (XSD, XSLT, XPath); still powers RSS, SVG, sitemaps and Office documents.

Weaknesses: verbose; closing tags roughly double the size; mapping to objects in code is clunkier.

Choose XML for: document formats, publishing workflows, legacy and enterprise integrations, anything requiring strict schemas.

YAML: configuration humans edit

Strengths: very readable; comments; multi-line strings; anchors and aliases to reuse blocks; YAML 1.2 is a superset of JSON.

Weaknesses: indentation errors are easy to make and hard to see; implicit typing can surprise you. In YAML 1.1 parsers, no or NO could be read as boolean false (the “Norway problem”), and 1.10 may become the number 1.1. Parsers are slower and more complex.

Choose YAML for: config files people edit by hand, such as Docker Compose, Kubernetes, GitHub Actions and CI pipelines.

Converting between formats

YAML to JSON is usually lossless, apart from comments and anchors.
JSON to YAML is lossless.
XML to JSON requires decisions: attributes vs elements, single items vs arrays, mixed content. Expect to write a mapping.

Quick decision guide

Machines talking to machines over HTTP → JSON
Humans editing configuration → YAML (or JSON with comments, such as JSONC, if your tool supports it)
Documents with rich markup, or strict enterprise schemas → XML

New to JSON? Start with JSON Syntax Basics: A Beginner's Guide With Examples, and keep Common JSON Errors and How to Fix Them handy for debugging.