JSON vs XML vs YAML: Choosing the Right Data Format

The same data, three ways

Below, one small object appears in all three formats. Comparing them side by side shows what each format trades off.

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

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

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

The same three fields take three very different amounts of punctuation. JSON suits machines best, YAML is the easiest to write by hand, and XML gives you the most structure when the document needs more than key/value data.

Where JSON wins

JSON maps onto the data structures every mainstream language already has (objects/dicts and arrays/lists), so parsing round-trips into native types with zero ambiguity. It has no comments, one way to write each value, and no whitespace sensitivity. Those limits make it fast to parse and safe to generate from code.

Use JSON for anything machine-to-machine: REST and GraphQL API payloads, data passed between services, anything stored in a document database (MongoDB, PostgreSQL's JSONB), and any config that code reads and writes more than people edit.

Where YAML wins

YAML is a strict superset of JSON's data model with a friendlier syntax for humans: no closing brackets to count, comments with #, and indentation in place of punctuation. You want that for files a person edits and re-reads in a diff: CI pipelines (GitHub Actions, GitLab CI), Kubernetes manifests, and application config.

That flexibility is also YAML's biggest footgun. An indentation error produces a different structure with no parse error, and the parser can convert unquoted values like `no`, `yes`, `on`, and dates to booleans or timestamps you didn't intend (the infamous 'Norway problem', where the country code NO becomes the boolean false). Quote your strings whenever a value could be read two ways.

Where XML wins

XML looks like legacy overhead next to JSON, but it handles things JSON and YAML can't: attributes alongside element content, mixed content (text and elements interleaved, like HTML), namespaces for combining vocabularies from different sources, and mature schema validation (XSD) plus transformation (XSLT) tooling that predates JSON by a decade.

XML persists in document-centric domains: SOAP APIs, SVG, DOCX/XLSX (ZIP files full of XML), and enterprise systems in banking, healthcare, and government with XSD-validated pipelines nobody plans to rewrite. If your data is document-shaped ('a paragraph with a bolded span in the middle') instead of record-shaped, XML often fits better.

Size and parsing speed

For the same record-shaped data, YAML is the smallest on disk, JSON lands within a few percent of it, and XML runs roughly 30–40% larger than JSON once you count closing tags and attributes or wrapper elements. A 1 KB JSON payload usually becomes a 950-byte YAML file and a 1.3–1.4 KB XML document. Those gaps matter for files on disk, payloads embedded in bundles, and anything stored uncompressed. Over HTTP they matter much less.

Compression explains why. Nearly every production API and CDN enables gzip or brotli, which squash repeated punctuation and indentation, and all three formats compress well. After brotli, the minified-JSON and pretty-YAML versions of the same data usually land within a few percent of each other. Parsing tells a similar story: JSON.parse is a native, heavily optimized code path in every browser and in Node, YAML needs a library and a far heavier grammar, and XML sits in between. You won't measure any of it for config parsed once at startup, but on a hot path JSON's cheap parser helps.

Comments, multi-document files, and other sharp edges

Comments: YAML has them (#), XML has them (<!-- -->), and JSON leaves them out on purpose. If two documents could differ only by a comment, implementations that strip or keep comments would disagree about equality, which breaks signatures, hashes, and cache keys.

Multi-document files: YAML separates documents with ---, so one file holds a stream of records. XML permits one root element. JSON defines a single value per document, and the ecosystem uses JSON Lines (one minified document per line) for streams. YAML also has anchors and aliases (&anchor / *alias) for reuse, which JSON has no equivalent for.

Each format has a characteristic sharp edge. With YAML's indentation sensitivity and implicit type coercion (the Norway problem), a file can parse into a different structure than you intended. XML's entity expansion opens an attack surface (the XXE vulnerability class) in misconfigured parsers, and namespaces add verbosity JSON never has. JSON's edges are milder: no comments, no date type, integer precision capped at 2^53. That makes it the safest of the three to accept from untrusted sources.

Converting between formats

All three describe the same object/array/string/number/boolean/null data model (XML's attributes and mixed content don't map cleanly), so converting record-shaped data between JSON, YAML, and XML is mechanical. JsonForge's JSON to YAML, YAML to JSON, JSON to XML, and XML to JSON tools convert in the browser, which helps when you migrate a config file's format or hand a YAML-only teammate a JSON export.

XML is the awkward direction. JSON has no distinction between attributes and child elements, so each converter adopts a convention (an @ prefix for attributes, or a fixed sub-object), and a document round-tripped through it comes back in a different shape. JSON ⇄ YAML conversion loses nothing in either direction.