JSON vs YAML vs XML: how to pick the right format

Three text formats dominate developer life: JSON, YAML, and XML. They’re often presented as interchangeable — you can convert between any of them, so surely it’s a preference thing. It’s not entirely. Each format fits a different job, and picking the wrong one is how you end up with a config file nobody can debug.

JSON: the data interchange standard

JSON is the default for APIs, databases, and structured data. Its strengths:

• Machine-friendly and universal. Every language parses it natively, and it maps cleanly onto the data types most code uses — objects, arrays, strings, numbers, booleans, null.
• Strict and predictable. One way to write a string, no alternative syntaxes. That strictness is why validators can tell you exactly where you went wrong.
• Types are explicit. "5" and 5 are visibly different. That matters more than people think.

Its weaknesses: no comments (a notorious pain for config), no multi-line strings without awkward \n escapes, and a stricter parse than people expect (see our post on the common JSON errors that break parsers).

YAML: the config language

YAML’s selling point is human readability for configuration — Kubernetes manifests, CI pipelines, docker-compose, Ansible. It’s JSON’s superset in many ways: YAML 1.2 can parse JSON, and YAML structures (maps, lists) map directly to JSON.

But YAML pays for readability with ambiguity:

• Indentation is syntax. A misplaced space silently changes meaning.
• The type system is quirky. yes/no/on/off can become booleans in older parsers, 0123 may parse as octal, and unquoted strings like null or 1.5 are type-coerced in ways that surprise people.
• Comments exist (a big win over JSON), but the format spec is sprawling, and subtle differences between parsers (YAML 1.1 vs 1.2) cause real bugs.

If you’re choosing YAML, you’re usually forced to by the tool — and the right response is to let a converter produce the JSON equivalent for a sanity check.

XML: the document format

XML is older, wordier, and built for a different purpose than data interchange. It shines where JSON and YAML fall short:

• Documents with mixed content — prose with inline markup (think HTML’s ancestor and word processors).
• Attributes and namespaces — richer metadata than JSON’s plain key/value model.
• Schemas that predate JSON — SOAP, RSS, SVG, many enterprise and government systems.

Its cost: verbosity (every node has open and close tags), no native boolean/null, and parsing that’s a whole class more complex than JSON. Converting XML to JSON also loses things JSON can’t represent well — attributes vs child elements, namespaces, ordering.

The decision rule

• Data between systems, APIs, storage: JSON.
• Configuration files, infrastructure-as-code: YAML — and keep the JSON equivalent close by for validation.
• Documents, feeds, legacy/enterprise integration: XML.

Converting between them

When you’re stuck with one format and need another — a YAML config you want to lint as JSON, an XML feed you need as JSON, a JSON payload a legacy system wants as XML — a JSON converter that handles JSON → YAML, XML, and CSV saves you the parser rabbit hole. Convert, sanity-check the output, and you’re done.

One warning, regardless of direction: conversions are not lossless. YAML types that don’t exist in JSON, XML attributes, and CSV’s total lack of nesting are all places where information gets flattened or invented. Convert for inspection and hand-off, not as a durable transformation you don’t review.