JSON to YAML Converter — Clean Output

Two formats for two audiences

JSON is unambiguous and verbose: every type is explicit and there is nothing to interpret. It is what programs exchange. YAML was designed to be written and read by people — configuration, CI pipelines, container manifests — and it buys that readability with implicit behaviour.

One genuinely useful fact: JSON is a valid subset of YAML, so any YAML parser will read JSON as-is. You can migrate a file gradually, or drop a JSON block inside YAML where precision matters more than looks.

Note the direction here — this converts JSON into YAML. The reverse needs a full YAML parser, which is a much larger problem than serialising.

Implicit typing, which is where YAML bites

YAML infers a value's type from how it looks. A bare word is a string unless it matches a pattern, and the patterns catch more than people expect.

The country-code case

A list of two-letter country codes written bare:

countries:
- NO
- SE

Under YAML 1.1 rules, which most parsers in the wild still follow, NO is read as the boolean false. The list silently loses Norway. Quote it — "NO" — and it stays a string.

Leading zeros become octal

An account reference or ID written 0700 is read as octal, giving the number 448. 01234 becomes 668. Not a formatting change — a different number.

Ambiguous booleans

yes, no, on, off, and even bare y and n are booleans to some parsers and strings to others. response: yes may mean true, or may mean the word. Which one you get depends on a library version you probably did not choose.

Version numbers get truncated

A version written 1.10 read as a number becomes 1.1, which is a different version. Similarly, a bare ISO date is read as a timestamp rather than text.

The habit that prevents nearly all of this is one line long: if a value is meant to be a string, quote it.

What the converter does about it

This is where the conversion earns its keep. When it writes a string that would change type as a bare value, it quotes it automatically — anything numeric-looking, any of the boolean or null keywords including on, off, y and n, and anything shaped like a date. So a JSON string "0700" comes out as "0700" rather than as a number waiting to happen.

What it cannot do is guess intent. If your JSON holds a real number, it stays an unquoted number, which is correct — the tool preserves what JSON told it, and JSON was explicit.

Indentation

YAML uses whitespace for structure, so a misplaced space changes the meaning rather than raising an error, and tabs are not permitted as indentation at all.

This is why YAML errors so often point several lines past the actual mistake: the parser accepted a different structure than you intended and only hit something impossible later. If an error makes no sense at the line it names, look above it.

The other direction, and comments

Worth knowing before you plan a round trip: YAML to JSON discards every comment, because JSON has no comment syntax. In a configuration file the comments are frequently the most valuable thing in it — why a setting exists, what breaks if you change it — and no conversion can carry them across.

So treat JSON as the wire format and YAML as the file humans maintain, rather than converting back and forth as though they were interchangeable.

Everything runs in your browser and nothing is uploaded. To check the JSON is well-formed first, use the JSON formatter.