YAML to JSON Converter
Convert YAML to JSON and see what your config actually parses to — including the classic YAML surprises, made visible.
See what your YAML really means
YAML is pleasant to write and notoriously full of surprises to parse. Converting it to JSON is the fastest way to see the truth: JSON has no implicit typing, so what you get here is exactly what Kubernetes, your CI runner, or any YAML consumer sees. If a value comes out as a string when you expected a number — that's not a converter quirk, that's your YAML.
The classic YAML traps, made visible
- The Norway problem — in old YAML 1.1 parsers,
country: NObecomesfalse. This converter follows YAML 1.2 (NOstays a string), and converting to JSON shows you unambiguously which reading you got. - Versions that become numbers —
version: 1.20parses as the number1.2. If you meant the string, YAML needs quotes:"1.20". - Times and octals —
port: 08orwhen: 12:30parse as strings or sexagesimals depending on dialect; the JSON output ends the guessing. - Tabs — YAML forbids tab indentation. You get the exact line and column instead of the usual cryptic parser complaint.
Errors with positions, JSON with your indent
Invalid YAML reports the precise line and column (same behaviour as the JSON Validator on the JSON side). Valid YAML converts to pretty-printed JSON with your chosen indent — ready for the formatter, the tree viewer, or your code.
Frequently asked questions
Why did my value come out as a string (or number) when I expected the other?
YAML types values implicitly: 1.20 is the number 1.2, "1.20" is a string, NO is a string in YAML 1.2 but false in old 1.1 parsers. The JSON output shows the parsed reality — if the type is wrong, add or remove quotes in the YAML source.
Are comments preserved?
No — JSON has no comments, so they are dropped by definition. If you need to round-trip a commented config, keep the YAML as the source of truth and generate JSON from it, never the reverse.
Does it handle anchors, aliases and merge keys?
Yes — anchors (&) and aliases (*) are resolved during parsing, so the JSON contains the expanded values. The output has no references, which is exactly what any JSON consumer needs.
What about multi-document YAML (--- separators)?
Paste one document at a time — the converter processes a single document and tells you where parsing stopped otherwise. Multi-doc streams are a k8s convenience, but each document is independent JSON anyway.
My YAML fails with "found character that cannot start any token" — what is it?
Nine times out of ten: a tab character used for indentation, which YAML forbids. The error position here points to the exact line and column — replace the tab with spaces.