YAML to JSON

Two reasons to go this direction. One is plumbing: something downstream only speaks JSON. The other is diagnostic — reading a YAML file tells you what it looks like it says, and converting tells you what it actually parses to. Those differ more often than the format's reputation for readability suggests.

Nested mappings, block sequences, inline flow collections ([1, 2] and {a: 1}), quoted scalars, and # comments are all handled. Structure comes from indentation, so misalignment is a parse error here rather than a silent change of meaning.

Why is my tab-indented file rejected?

The YAML spec forbids tabs for indentation, and most editors render them identically to spaces — which makes this one of the harder bugs to find by reading. Converting is a fast way to locate it: the error names the line.

Will unquoted values keep their YAML types?

Yes, and that is the point of running this. enabled: yes gives you true, and zip: 10001 gives you a number. If either surprises you, the YAML needed quotes — better to find out here than in the service that consumes it.

Are anchors and aliases supported?

No. Anchors (&name), aliases (*name), merge keys (<<), and multi-document streams split by --- are out of scope. Ordinary data YAML — the kind a CI config or a Helm values file is made of — works.

What happens to comments?

They are dropped, because JSON has nowhere to put them. Worth knowing if you were planning to convert a documented config, edit the JSON, and convert back: the prose does not survive the trip.