Fun Data Playground yaml → json
Field types Account← Generator

Home YAML to JSON

YAML to JSON converter

Paste a Kubernetes manifest, a GitHub Actions workflow, a docker-compose file or an OpenAPI spec and get JSON back. It runs in this tab, follows YAML 1.2 and says exactly which line is wrong when something is.

Other languages:TürkçeDeutsch中文हिन्दीРусский

Which YAML: the 1.2 rules, and why it matters

The same unquoted value means different things to different YAML parsers. YAML 1.1 — still what PyYAML reads — has a long list of implicit types; YAML 1.2 cut it down to true/false, null and plain numbers. This converter uses the YAML 1.2 core schema — the one the specification recommends, and the basis of js-yaml's default:

Unquoted YAMLPyYAML (YAML 1.1)Here (YAML 1.2)
NOfalse"NO"
yes / ontrue"yes" / "on"
010810
12:30750"12:30"
2024-01-01a date"2024-01-01"
1_0001000"1_000"
1e3"1e3"1e3

If a file was written for a YAML 1.1 tool and relies on yes meaning true, the JSON here will say "yes" — which is the honest answer to “what does this file say” and a signal that the value should have been true. Note one case that neither version protects: zip: 007 is the integer 7 in both. If leading zeros matter, the YAML has to quote them.

What it reads

  • Block mappings and sequences, including the Kubernetes style where a list sits at the same indentation as its key.
  • Flow collections — [a, b] and {k: v} — across lines.
  • Every scalar style: plain (including multi-line), single- and double-quoted with all YAML escapes, literal | and folded > blocks with +/- chomping and indentation indicators.
  • Anchors, aliases and merge keys (&defaults, *defaults, <<: *defaults) — merged keys resolve in place, and a key written out later wins.
  • Multiple documents separated by --- become a JSON array, one element per document.
  • Standard tags such as !!str and !!int are applied. Custom tags — CloudFormation's !Ref and !Sub, for instance — have no JSON meaning, so the tag is dropped with a warning and the value kept.

Large integers keep every digit, so an ID such as 12345678901234567890 is not rounded on its way into the JSON. Before release the parser was compared with js-yaml on 140 real-world files — CI workflows, package configs, OpenAPI documents — and produced the same JSON for every one.

What JSON cannot hold

Comments are dropped — JSON has nowhere to put them. .inf and .nan have no JSON equivalent and are kept as strings, with a warning. Complex keys (? key) are reported as unsupported rather than guessed at.

Errors it reports

Each error carries its line number, and the line is shown under it. The common ones: a tab used for indentation (YAML allows only spaces), a duplicate key in the same mapping (most parsers reject it; some silently keep one), an unquoted ": " inside a value, an alias to an anchor that is not defined above it, and a flow collection that is never closed.

Common questions

Why is NO a string instead of false?

Because the converter follows the YAML 1.2 core schema, where only true and false (in any case) are booleans. YAML 1.1 tools such as PyYAML read NO, yes, on and off as booleans; if your file relies on that, write true or false explicitly.

Does it support anchors and merge keys?

Yes. Anchors and aliases resolve to copies of the anchored value, and merge keys (<<: *defaults, or a list of aliases) insert the anchored keys, with keys written out in the mapping taking precedence.

What happens to a file with several YAML documents?

Each document separated by --- becomes one element of a JSON array, in order. A file with one document converts to that document alone.

Are comments kept?

No. JSON has no comment syntax, so there is nowhere to put them. Everything else in the document — keys, order, values — is carried over.

What about CloudFormation tags like !Ref?

Custom tags have no JSON meaning, so the tag is dropped and its value kept, with a warning naming the line. !Ref MyBucket becomes the string "MyBucket".

Last updated