JSON YAML Converter

YAML is readable right up until it silently corrupts your data

The original pitch was config files you can read and write without a dedicated tool. That pitch is accurate for the happy path. Kubernetes manifests, GitHub Actions workflows, Docker Compose files, Ansible playbooks — YAML works for all of those, and it does stay readable. The problem shows up in the edge cases: indentation is structural (a tab where a space should be is a parse error), and YAML 1.1 — which a lot of parsers still use — will turn yes into true and NO into false without telling you. Norway's country code is "NO." Ask anyone who's tried to use it as a YAML value how that went.

YAML anchors (&) and aliases (*)

Define a block once with &name, reference it elsewhere with *name. Without this you'd repeat the same job config eight times in a CircleCI file and they'd drift out of sync within a week. Kubernetes configs use anchors for shared container specs. It's one of the genuinely useful features YAML has that JSON doesn't.

Literal block scalar | vs. folded block scalar >

Pipe (|) keeps every newline exactly where you put it. Use it for shell scripts, SQL, or any multi-line string where line breaks are meaningful. Greater-than (>) folds newlines into spaces, turning your multi-line text into a single paragraph when parsed. Use it for prose descriptions in config files where you want the YAML to wrap nicely but the resulting string to be continuous.

The boolean trap

YAML 1.1 treats yes, no, on, off, true, and false as booleans. All of them. YAML 1.2 cut that back to just true and false. Python's PyYAML defaulted to 1.1 behavior through version 5.x. So a survey response of "yes," a feature flag of "on," or a country code of "NO" would silently become a Python boolean in your data. No warning, no error.

Unquoted numbers that aren't numbers in your source

Write version: 1.0 and YAML parses it as the float 1.0. Write version: 2.10 and some parsers give you 2.1 because trailing zeros aren't significant in floating-point. Quote anything that needs to stay a string: version: "2.10". That's it.

The simple rule: YAML for humans writing it, JSON for machines exchanging it

If a person is going to open the file, edit it, and commit it to version control — and inline comments would help — YAML is the right call. If a program generates the file and another program reads it, or you need strict schema validation, or the consumer is a REST API or a database — JSON. The common pattern in real pipelines is to keep YAML as the source of truth that developers touch and convert to JSON before automated processing. That's not a compromise. That's actually how it's meant to work.