JSON to YAML Converter

Paste JSON on the left and the YAML appears on the right as you type, no Convert button to press. The instant output is convenient, but what actually matters is what happens to your values as they cross from JSON into YAML. YAML tries to be helpful by guessing whether a bare word is a string, a number, or a boolean, and every so often it guesses wrong and quietly rewrites your data. This JSON to YAML converter watches for exactly those cases and quotes around them, so the YAML you copy parses back to the same thing you started with. On top of that it hands you control most free converters skip. Switch between 2 and 4 space indent, sort the keys A to Z for clean diffs, or drop a whole .json file onto the box instead of pasting. It all runs in your browser, so nothing you paste leaves the page, and there is no upload and no sign-up.

1. Add your JSON. Type or paste it into the Input box, click Open .json file, or drag a file straight onto the box. Any valid shape works, a single object like {"port":8080}, an array of objects, or a deep config tree.
2. Watch it convert. There is no button to click. The YAML rebuilds the moment you change the input or a setting, and a small status line tells you how many lines came out.
3. Set the indent. Two spaces is the default, which is what Kubernetes and Docker Compose expect. Click 4 spaces if your project's style guide wants the wider nesting.
4. Sort the keys if you want a canonical order. Turn on Sort keys A to Z and every mapping comes out alphabetized, top to bottom, no matter what order the JSON was in.
5. Copy or download. Copy output puts it on your clipboard, Download .yaml saves a file for your repo, and the Share link carries your exact settings to anyone who opens it.

If the input is not valid JSON, the output box stays empty and a red message points at the likely cause, usually an unquoted key, a trailing comma, or a missing brace. Fix the input and it reconverts on its own. It never crashes on bad input, it just tells you what tripped it up.

This is where a naive "delete the braces and add whitespace" approach falls apart. YAML is clever about types, so when it sees a bare word it decides for you whether you meant a string, a number, a boolean, or null. Most of the time that guess is right and saves you a lot of quotes. Sometimes it is wrong in a way you never notice until something downstream breaks.

The Norway problem

This is the classic case, where YAML reads a pile of bare words as booleans: yes, no, on, off, true, false. So if your data holds a list of country codes and one of them is Norway's NO, a plain parser turns it into the boolean false. Your two-letter string is gone, replaced by a false nobody typed, the moment the parser saw the bare word.

country: no    # parses as the boolean false
country: "no"  # stays the string "no"

The converter quotes any value that matches one of those words, so your NO comes out as "no" and stays the string it was in your JSON. You do not have to remember the trap, because the tool already does.

Numbers that were supposed to be strings

The same guessing catches numeric-looking strings. A US ZIP code like 02134 has a meaningful leading zero, but bare in YAML some parsers read that zero as octal and hand back a different number. A version string like "1.10" collapses to the float 1.1 and loses its trailing zero. Phone numbers, SKUs, any ID with leading zeros, all of them need to stay strings. The tool wraps anything that looks like a number so the digits survive as typed.

zip: "02134"     # keeps the leading zero
version: "1.10"  # stays "1.10", not 1.1

Colons, hashes, and stray indicators

A colon is how YAML separates a key from its value, so a value that contains one is ambiguous and gets quoted. A # starts a comment, so a value with one in it could get cut off partway through, that gets quoted too. Same goes for empty strings (so they do not read as null), strings padded with leading or trailing spaces, and anything starting with a YAML indicator character like a dash or a bracket. A date-shaped value gets the same treatment for the same reason as Norway: 2024-01-15 left bare comes back from a 1.1 parser as a date object rather than the text you wrote, so if (v == "2024-01-15") stops matching and serializing it back to JSON blows up. The rule behind all of it is that if leaving a string bare would change what it means, quote it, and otherwise leave it clean so the output stays readable.

Most free converters lock you into whatever indent they picked. This one lets you choose. Two spaces per level is the community default and what the big config tools expect, so that is where the converter starts. Some teams prefer four because the extra width makes deep nesting easier to read. One click switches between them and the output redraws right away, and because YAML forbids tabs for indentation the tool only ever writes spaces.

Sorting keys is the other control. JSON keeps keys in the order they were written, and so does this converter by default, because that order often carries meaning a person put there. Flip on Sort keys A to Z and every mapping comes out alphabetized at every level of nesting. That helps most when you compare two configs that describe the same thing but were assembled in different orders, because sorting lines the keys up so the real differences stand out instead of hiding behind reordering noise. Both settings travel in the Share link, so a URL you send opens the tool the way you had it.

If you have touched modern infrastructure, you have written YAML whether you meant to or not. Kubernetes manifests, a docker-compose.yml, GitHub Actions workflows, Ansible playbooks, and a pile of app config files are all YAML, because humans hand-edit those and readability wins. JSON owns the other job, the format systems use to talk to each other, an API response or the package.json a package manager parses strictly, so the two are not really competing. You reach for this converter when an API dumps some JSON at you and you need it as a readable config block you can hand-edit. One quirk on top of that: every JSON file is already valid YAML, because the YAML 1.2 spec is a superset of JSON, so going the other way, into the indented block style you actually want to read, is the part the tool handles.

For a hundred files at once, or conversion wired into a script, a command-line tool like yq (yq -P file.json) is the better pick, and inside your own app a library gives you full control. A browser tab is for the one-off, the snippet you are turning into a manifest right now, and for the times your JSON holds something you would rather not send off to a stranger's server.