JSON / YAML
Convert between the two, preserving key order
JSON and YAML describe the same data model — maps, sequences and scalars — with very different priorities. JSON is explicit and machine-first: every string quoted, every structure bracketed, no comments. YAML is written for people, using indentation instead of braces and allowing comments, anchors and multi-line strings.
Because the models line up, converting between them is mechanical, and it is a routine task: Kubernetes manifests and CI pipelines are YAML, while APIs and config loaders speak JSON. YAML is in fact a superset of JSON, so valid JSON is already valid YAML — the interesting direction is the other one, where YAML features with no JSON equivalent have to be resolved.
How to use it
- Paste either formatThe input is parsed as whichever it is; the opposite representation appears alongside it with key order preserved.
- Read errors by lineA parse failure is reported at the line that caused it. In YAML the reported line is often just after the real mistake, because indentation errors only become unambiguous on the following line.
- Check what did not surviveComments and anchors have no JSON equivalent and are lost in that direction. If a YAML file is your source of truth, keep it that way rather than round-tripping through JSON.
Frequently asked questions
Is YAML really a superset of JSON?
Since YAML 1.2, yes — any valid JSON document is valid YAML, and a YAML parser will read it. The reverse is not true, because YAML adds comments, anchors and aliases, multiple documents in one file, and unquoted scalars. Those are exactly the features that cannot survive conversion to JSON.
Why did my YAML value become true when I wanted the string "yes"?
This is the Norway problem. YAML 1.1 parsers treat yes, no, on, off, y and n as booleans, so the country code NO becomes false. YAML 1.2 narrowed that to true and false only, but plenty of tooling still implements 1.1. Quote any scalar whose meaning matters.
What happens to comments when I convert to JSON?
They are discarded, because JSON has no syntax for them. That is the strongest argument for keeping YAML as the authored format and treating JSON as an output. If you need annotations that survive, they have to become data — a description field, for instance.
Why does indentation break my YAML so often?
Because indentation is structure, and tabs are forbidden entirely — YAML requires spaces. A single misaligned key silently reparents a block rather than failing loudly, so a file can be valid YAML and still mean something you did not intend. Converting to JSON is a quick way to see the structure you actually wrote.
Are leading zeros safe in YAML?
No. A value such as 0755 may be read as octal, and a version number like 1.10 becomes the float 1.1, losing the zero. Anything that looks numeric but is really an identifier — postcodes, version strings, file modes — needs quoting.