All formats
JSON vs YAML
YAML is what humans edit: comments, no brackets, roughly 30 percent fewer characters for the same structure. JSON is what machines parse: faster, unambiguous, supported natively everywhere. Config files people maintain by hand tend to be YAML. Anything crossing a network is JSON.
Side by side
| Spec | JSON | YAML |
|---|---|---|
| Type | Data | Data |
| Extensions | .json | .yaml, .yml |
| Introduced | 2001 (ECMA-404 in 2013) | 2001 |
| Compression | None | None |
| MIME type | application/json | application/yaml |
| Use it when | API payloads, configuration and any nested data structure. | Human-edited configuration: CI pipelines, Kubernetes, application config. |
| Avoid it when | You need comments or anchors in config (use YAML), or flat tabular data (use CSV). | Machine-to-machine payloads where JSON is simpler and faster to parse. |
Where the usual answer breaks
YAML's implicit typing has real traps. The country code NO parses as the boolean false unless quoted, which is why some teams stay on JSON.
JSON
- Native support in virtually every programming language
- Human-readable and simple to validate
- Handles nested and hierarchical data cleanly
- No comments, which makes it awkward for configuration files
- No date type, so dates are strings by convention
- Verbose compared with binary formats
YAML
- Supports comments, unlike JSON
- Less punctuation, so configuration reads more cleanly
- Anchors and aliases let you reuse blocks
- Whitespace-sensitive, so indentation mistakes break files silently
- The full specification is large and implementations differ
- Ambiguous scalars: unquoted values can parse as unexpected types
Convert between JSON and YAML
Tools for these formats
Other comparisons
Last updated 2026-08-03