Convert YAML to JSON

How to use it#

1. Drop a .yaml or .yml file on the box at the top, or paste your YAML into the text box under it. A dropped file opens in the text box, where you can edit it.
2. Pick 2 or 4 spaces of indentation for the JSON, and tick Sort keys to put the keys in alphabetical order.
3. Read the result, or the error naming the line that failed.
4. Copy it, or download it as a .json file named after the one you dropped.

What YAML has that JSON does not#

Comments are the big one. A YAML config is usually half explanation, and none of it survives the trip: JSON has no comment syntax at all, so every line beginning with a hash is simply gone from the output. If the comments are the documentation for that config, keep the YAML.

Anchors and references go the same way. YAML lets you define a block once and reuse it with & and *, and JSON has no equivalent, so the content is written out in full at each place it was referenced. The result means the same thing and is longer.

Merge keys are expanded as well. A Docker Compose file or a GitLab CI config often starts with a block of shared settings and pulls it into each service with <<: *defaults. Each of those becomes a plain object holding the shared keys, and a key written beside the merge wins over the shared one, just as Compose and GitLab read it.

Multiple documents in one file, separated by ---, have no JSON equivalent either. Those come back as an array, which is the closest JSON can get to the idea.

The type surprises#

YAML guesses types, and the guesses are the source of most of its bug reports. A bare 3 is a number, "3" is a string, and the difference decides whether your config works. Converting to JSON makes that visible: whatever YAML decided, you can now see it as a quoted string or a bare number.

The classic trap is a value that looks like something else. A version written as 1.20 is the number 1.2, which loses the zero. A country code like NO, or a key like on, used to be read as booleans under older YAML rules, which is why configuration files are full of quotes around apparently ordinary words. Current YAML is stricter, but the habit persists for good reason. The YAML validator lists every bare value in a file that the two sets of rules read differently.

Times and dates are worth watching too. Something like 22:30 is read as a string by modern YAML, while older parsers treated colon-separated numbers as base 60. If a value matters, quote it.

When the file will not parse#

Almost every YAML error is indentation. The format uses spaces to mean structure, so a line indented one space too far belongs to a different parent than you intended, and a line that mixes tabs with spaces is rejected outright because tabs are not allowed for indentation at all.

That makes the converter a quick way to validate YAML, or lint it for syntax, before it reaches a deploy. The message under the box comes from the parser and names the line and column where it gave up. As with most parsers, that is the point where the problem became undeniable rather than the point where it started, so the real mistake is often a line or two above.

Nothing here executes#

A YAML parser can be told to construct arbitrary objects from tags in the document, and historically that made parsing an untrusted YAML file a way to run code. Modern parsers default to a schema with no such tags, which is what this uses, so a document that asks for one is rejected rather than obeyed.

It is worth knowing about because the same is not automatically true elsewhere. In Python, yaml.load without a loader argument was the well known case, and yaml.safe_load is the answer there.