YAML to JSON

Every JSON file is YAML; the reverse is not true

YAML is a superset of JSON, so any JSON document is already valid YAML. Going the other way means deciding what to do with everything YAML has that JSON does not: comments, anchors and aliases, multiple documents in one file, multi-line block scalars, dates as a native type, and a set of untagged scalars whose type is inferred from how they are written.

That last one is where the surprises live. In JSON, "no" is unambiguously a string. In YAML, what no means depends on which version of the spec your parser implements — and parsers disagree.

What your values turn into

Here is exactly what this converter produces, value by value. Several of these differ from what other YAML tools will give you, which is precisely why it is worth seeing the real output rather than assuming.

The Norway problem, and why it does not bite here

The famous case: a list of country codes containing NO for Norway, loaded by a YAML 1.1 parser, which reads no as boolean false. Norway disappears from the map.

This converter follows the YAML 1.2 core schema, where only true and false are booleans — so no, yes, on and off all stay strings, as the table above shows. That is the modern, correct behaviour.

It is still worth knowing about, because the file you convert here may be read elsewhere by something that implements YAML 1.1 — which includes PyYAML in its default configuration, and plenty of tooling built on it. A file that converts cleanly here can still be misread by the next tool in the chain. Quoting protects you from all of them.

Anchors, aliases and merge keys are resolved

YAML lets you define a block once and reuse it. JSON has no such concept, so the converter expands everything — the output contains the fully resolved values.

defaults: &defaults
  retries: 3
  timeout: 30
job_a:
  <<: *defaults
  timeout: 60
job_b:
  <<: *defaults

{
  "defaults": { "retries": 3, "timeout": 30 },
  "job_a":    { "retries": 3, "timeout": 60 },
  "job_b":    { "retries": 3, "timeout": 30 }
}

Note that job_a correctly keeps its own timeout: 60 — a merge key supplies defaults, it does not override what is written explicitly. The anchor definition itself remains in the output as an ordinary key, because it was an ordinary key in the source.

What gets rejected, and what it means

Duplicate keys are the exception: a: 1 followed by a: 2 is accepted, and the last value wins. That matches JSON parsing behaviour, and it means a duplicated key in a long config file will not announce itself. Run the result through the analyzer if a value is not what you expected.

Why converting untrusted YAML is safe here

YAML deserialization has a genuinely bad security history. The dangerous pattern is a parser that instantiates arbitrary objects from tags — !!python/object/apply in PyYAML's unsafe loader is the classic remote-code-execution vector, and !!js/function was the JavaScript equivalent.

Two things prevent that here. The loader uses the default schema, and in js-yaml v4 the object-instantiating types were moved into a separate package that is not installed — so !!js/function produces "Unknown tag" rather than a function. And the conversion runs in your browser on a static page with no network call, so there is no server to compromise and no copy of your file anywhere.

Binary values (!!binary) are decoded and re-encoded as base64 strings, and native dates become ISO 8601 strings, so the JSON you get back is plain data with nothing exotic in it.

After converting

The output is formatted JSON, ready to send to an API or load in code. Two things are usually worth doing next: open it in the viewer to confirm the structure matches what you expected — deep YAML indentation hides mistakes that a tree makes obvious — and check the analyzer findings for fields that changed type unexpectedly.

If you need to go the other way, the JSON to YAML converter handles the return trip, with the caveat that comments cannot come back: they were discarded at parse time and nothing can reconstruct them.