YAML to JSON converter

The conversion is the easy part

Any converter can turn YAML into JSON. What almost none of them tell you is that the same YAML file means different things to different parsers, silently, and that the differences land precisely on the kinds of values people put in configuration files.

There are two YAML versions in active use. This page follows YAML 1.2, which is what JavaScript's parser and Go's implement. PyYAML and Ruby's Psych follow YAML 1.1. Measured against each other:

• no is the string "no" under 1.2 and the boolean false under 1.1. This is the famous one — it is why Norway's country code NO turns into false in a country list, and it has broken real deployments.
• 0644 is the decimal number 644 under 1.2 and octal 420 under 1.1. If that value is a file permission, the two readings are entirely different permissions.
• 00123 is 123 under 1.2 and 83 under 1.1, for the same octal reason.
• 12:30 is the string "12:30" under 1.2 and the number 750 under 1.1, because YAML 1.1 has base-60 integers.
• 2026-03-04 is a string under 1.2 and a date object under 1.1.
• yes, on and off behave like no.

So every value in your file whose meaning depends on that choice is found and listed with its line number, along with what the other kind of parser would make of it. Neither parser is wrong — each is correct for the version it implements — but a tool that shows one answer and stays quiet is hiding the thing most likely to break something.

The fix, when you see one of those

Quote it. "no" and "0644" are unambiguous strings in every version of YAML, and quoting a value costs nothing. There is an option here to quote every string on the way out, which is worth using for a file that will be read by more than one language.

What JSON cannot hold

YAML has .inf and .nan. JSON has no way to write either, so they become null — and that is a limitation of JSON rather than of the conversion, so there is no correct output to produce instead. It is called out when it happens, because a numeric field that has quietly become null is worth knowing about.

Comments go too. YAML comments carry a great deal of the meaning in a real configuration file and JSON has nowhere to put them, so a round trip through JSON is a way to lose all of your documentation.

Multi-document files

A YAML file separated by --- holds several documents, and Kubernetes manifests are usually written that way. Most converters read the first one and either ignore or choke on the rest. Here every document is read and the output is a JSON array, which is the honest representation.

Duplicate keys are an error, not a merge

If a key appears twice in the same mapping, this refuses the file and tells you the line. YAML 1.1 parsers typically keep the last one silently, which means a mistyped or copy-pasted key produces a config that runs with the wrong value and never complains. Refusing is the more useful behaviour.

Nothing is uploaded, and that matters more here

A YAML file is a configuration file. Configuration files hold database passwords, API tokens, connection strings and internal hostnames. Pasting a manifest into a website to reformat it means handing over the shape of an internal network, and quite often a live credential.

The conversion runs in this page. There is nothing to upload it to.

Going the other way

JSON to YAML gives you readable YAML with no line folding — long strings stay on one line, because a folded string is valid, startling, and awkward to diff. Anchors are not generated, since JSON cannot contain a shared reference for one to point at.

One thing YAML itself forbids: tabs for indentation. Ask for tabs and you get two spaces and a note saying why, because the alternative is producing a file that no YAML parser will read.