ToolVaults

JSON vs YAML: When to Use Which

Both encode the same shape of data, but they optimise for different readers. Here is how to choose.

Updated Aug 14, 20266 min read

JSON and YAML are both text formats for structured data. Give them the same object and you get two documents that mean the same thing. So why do we have two? Because they were designed for different readers — JSON for machines that need speed and unambiguous parsing, YAML for humans who need to read and edit a config without counting braces.

The one-minute version

  • Use JSON for API payloads, browser fetch bodies, and anything a JavaScript engine will parse hot.
  • Use YAML for hand-edited config: CI pipelines, Kubernetes manifests, Docker Compose, app settings.
  • Never store secrets in either. Both are plain text.

What actually differs

Whitespace matters in YAML

In JSON, whitespace is decorative — {"a":1} and { "a" : 1 } parse identically. In YAML, indentation is syntax. Two spaces vs four spaces is the difference between a nested map and a syntax error. This is what makes YAML easier to read and easier to break at 11pm.

YAML has anchors, JSON does not

YAML lets you name a chunk of a document and reuse it:

defaults: &defaults
  timeout: 30
  retries: 3

dev:
  <<: *defaults
  debug: true

prod:
  <<: *defaults
  debug: false

JSON has no equivalent — you would copy-paste the shared block into both objects. When you convert YAML to JSON the anchors get resolved and flattened, so the JSON output repeats itself. That is a feature, not a bug: the JSON is safe for machines that would otherwise need a YAML library to understand the references.

YAML supports comments, JSON doesn't

# starts a comment in YAML. JSON has none — a comment is a parse error. When you round-tripYAML → JSON → YAML, your comments are gone forever.

YAML has more types (and more surprises)

JSON has strings, numbers, booleans, null, arrays, and objects. YAML has all those plus dates, sets, ordered maps, and a legendary type-inference layer where no can parse as the boolean false,2:30 can parse as base-60, and unquoted country codes can flip to booleans. YAML 1.2 tightened this but every parser has quirks. When in doubt, quote your string values.

The "which one should I use" table

  • REST API payload → JSON. Every HTTP client speaks it natively, and it is smaller on the wire.
  • GitHub Actions workflow → YAML. You will re-read this file weekly; you never want to count braces.
  • Configuration for a Node/Python app → YAML for human-edited, JSON for programmatically written.
  • Storage/database column → JSON. Databases have JSON operators; YAML support is exotic.
  • Snapshot testing / diff-friendly file → JSON with sorted keys. Consistent ordering makes diffs meaningful.

Going back and forth

The JSON ↔ YAML Converter handles both directions in the browser. It resolves anchors and merge keys on the way to JSON and cleanly renders nested structures on the way to YAML. The one thing it can't recover is your YAML comments — those are lost the first time you go through JSON. If comments matter, treat YAML as your source of truth and JSON as the derived artifact.