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.
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
fetchbodies, 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.