JSON to YAML Converter

YAML is a strict superset of JSON, which makes this direction the easy one. Every JSON construct has a direct YAML equivalent: objects become mappings, arrays become sequences, and the scalar types line up exactly. Nothing has to be approximated or dropped, so the round trip back to JSON returns the same document.

What changes is the syntax and the amount of it. YAML expresses nesting with indentation rather than braces, so the punctuation largely disappears. A three-level JSON object with its braces, brackets, quotes and commas typically becomes noticeably shorter and, for most readers, easier to scan.

That readability is why the ecosystem settled on YAML for anything humans author by hand. Kubernetes manifests, Docker Compose files, GitHub Actions workflows, Ansible playbooks and OpenAPI documents are all YAML, and all of them could equally have been JSON.

In JSON every string is quoted, so the question never comes up. YAML infers types from the shape of a scalar, which means some strings must be quoted to stop them being read as something else - and knowing which is the main subtlety of writing YAML by hand.

The famous case is `"yes"`, `"no"`, `"on"`, `"off"`, `"true"` and `"false"`. Under the YAML 1.1 rules that many parsers still implement, all of these become booleans if unquoted. This is the origin of the so-called Norway problem: the country code `NO` becomes `false`, which has broken real configuration files. YAML 1.2 narrowed the boolean set to just `true` and `false`, but plenty of deployed parsers predate it.

Version strings are the other frequent trap. Unquoted `1.10` is the number 1.1, so a version pin silently changes. And a leading zero can be read as octal, which is how `08` becomes an error and `0755` becomes 493. A converter handles all of this by quoting whatever needs quoting, which is a good reason to convert rather than hand-translate.

Comments are the big one, and often the reason for converting in the first place. YAML supports `#` comments, so a converted document can be annotated - which is exactly what configuration files need and exactly what JSON cannot provide.

Anchors and aliases let you define a block once and reference it elsewhere, removing duplication that JSON has to repeat verbatim. Multi-line block scalars, written with `|` or `>`, hold embedded scripts or certificates readably instead of as one long line full of `\n` escapes. Multiple documents can share a file, separated by `---`.

All of these are one-directional gains. Convert back to JSON and comments, anchors and block formatting are gone, because the JSON data model has nowhere to put them. The values survive; the annotation does not.