JSON to YAML Converter
YAML output that quotes the values which would otherwise change type on the way back.
YAML is a superset of JSON — and that is the trap
Every valid JSON document is also valid YAML, so converting JSON to YAML is always syntactically possible. The difficulty is that YAML has a richer implicit typing system, and a scalar that was an unambiguous string in JSON may be re-read as something else. Quoting is how you prevent that.
| JSON value | Naive YAML output | Read back as | Correct output |
|---|---|---|---|
"true" | true | boolean true | "true" |
"no" | no | boolean false (YAML 1.1) | "no" |
"007" | 007 | number 7, or refused as a bad octal in YAML 1.2 | "007" |
"1.0" | 1.0 | float | "1.0" |
"" | (nothing) | null | "" |
"2026-01-15" | 2026-01-15 | a date object in some readers | "2026-01-15" |
"null" | null | null | "null" |
The Norway problem
Under YAML 1.1 — still the default in several widely deployed libraries — the unquoted country code NO parses as the boolean false. That single mis-typing has taken down production configuration often enough to have its own name. Countries whose codes collide with booleans and nulls include NO, YE, ON and OFF in various engines. YAML 1.2 largely fixed the set, but you do not control which parser your users have, so quote anything that could be misread.
Indentation is syntax, not style
- Tabs are forbidden for indentation. A tab character where a space is expected is a parse error in every conforming parser.
- Indentation must be consistent within a block. Mixing two and four spaces produces a valid file with a different structure than you intended.
- A sequence item under a mapping key goes on the next line, indented, with
-introducing each element. - Colons inside unquoted scalars must be followed by a space to be treated as a key separator — which is why URLs in YAML are best quoted.
Safety: anchors, aliases and the billion laughs
YAML supports anchors (&name) and aliases (*name) that reference earlier nodes, plus merge keys. These are extremely useful for config files and extremely dangerous for untrusted input: a small document using nested aliases can expand to gigabytes of memory — the billion laughs attack. Any YAML parser fed untrusted input must use a safe loader with alias expansion disabled or bounded. JSON has no equivalent feature, which is one reason APIs prefer it.
For machine-to-machine communication, prefer JSON. Use YAML where a human edits the file — Kubernetes manifests, CI configuration, Ansible playbooks — because comments and multi-line strings matter there. The format choice should follow who writes it.
How to use it
- Paste JSON.
- Convert — strings that resemble booleans, numbers or null are quoted automatically.
- Check the indentation uses spaces only.
- Read the result back with your target parser before committing it.
Worth knowing
- YAML 1.2 is a strict superset of JSON, so any JSON is also valid YAML.
- In YAML 1.1 the unquoted
NOparses as the boolean false — the Norway problem. - Tabs are illegal for indentation; only spaces are permitted.
- Anchors and aliases enable the billion laughs memory-expansion attack.
Limitations
- Implicit typing differs between YAML 1.1 and 1.2 parsers, so quote defensively.
- Anchors, aliases and tags are not generated — JSON has no equivalent constructs.
- Comment style cannot be preserved because JSON carries no comments.
- Deeply nested output becomes hard to read and easy to mis-indent by hand.
Frequently asked questions
Is YAML better than JSON?
Why are my strings being quoted?
"true", "no", "007" and "1.0" are all quoted so they stay strings rather than silently becoming booleans, numbers or null.Why does my YAML fail to parse?
What is the Norway problem?
NO being read as the boolean false by YAML 1.1 parsers. It illustrates why implicit typing in YAML requires quoting anything ambiguous.