JSON vs YAML vs XML: When to Use Each Format (With Examples)

July 8, 2026

All three formats describe structured data, and all three are still widely used in 2026 — the question isn't which one is "best" in the abstract, it's which one fits a given job. Here's a practical breakdown, with the same example data shown in each format.

The Same Data, Three Ways

JSON:

{
  "service": {
    "name": "api-gateway",
    "port": 8080,
    "replicas": 3,
    "env": ["production", "staging"]
  }
}

YAML:

service:
  name: api-gateway
  port: 8080
  replicas: 3
  env:
    - production
    - staging

XML:

<service>
  <name>api-gateway</name>
  <port>8080</port>
  <replicas>3</replicas>
  <env>production</env>
  <env>staging</env>
</service>

Where Each One Actually Wins

Use Case	Best Format	Why
REST API request/response bodies	JSON	Native to JavaScript, universally parsed, minimal syntax overhead
CI/CD pipeline configs (GitHub Actions, GitLab CI)	YAML	Comments are supported; whitespace structure reads cleanly for humans editing by hand
Kubernetes manifests	YAML	Ecosystem convention; nearly all Kubernetes tooling assumes YAML input
SOAP APIs, legacy enterprise systems	XML	Required by the protocol; strong native support for namespaces and attributes
Documents with mixed content (text + markup, like a book chapter)	XML	Attributes and mixed text/element content model this naturally; JSON and YAML don't have an equivalent
Local app config files	YAML or JSON	YAML if humans edit it directly; JSON if it's machine-generated only

The Real Trade-offs

JSON has no comments and no multi-line strings without escaping — bad for hand-edited config, excellent for machine-to-machine payloads because every mainstream language parses it natively with zero extra dependencies.

YAML is the most human-readable of the three but its whitespace sensitivity is a real source of bugs — a single misaligned indent silently changes what a value belongs to, and its type coercion rules have famously bitten people (the Norway problem: an unquoted no parses as the boolean false, not the string "no").

XML is verbose and slower to parse than the other two, but its schema validation (XSD) and namespace support are more mature than JSON Schema, which matters in industries with strict document-interchange standards (finance, healthcare, government).

Generating Test Data in Any of the Three

If you need sample data to test a parser or pipeline in any of these formats, build the schema once and export in whichever format the job calls for — Dummy JSON Generator supports JSON, CSV, and SQL output from the same field definitions, so you're not maintaining separate sample files for JSON vs other formats by hand.

The Bottom Line

Use JSON for API payloads and anything machine-to-machine, YAML for config files humans actually read and edit, and XML when you're integrating with a system (SOAP, legacy enterprise, strict document standards) that requires it. None of the three is objectively "better" — the right choice depends entirely on who or what is reading the file.