JSON to YAML Converter (and YAML to JSON)

What is a JSON to YAML converter?

A JSON to YAML converter rewrites a JSON document as YAML: the same nesting and the same values, expressed with YAML’s indentation instead of braces, brackets and commas. This one runs entirely in your browser and works in both directions. Flip the toggle and it becomes a YAML to JSON converter, turning a YAML file — or plain JSON, since every valid JSON document is already valid YAML — into indented or minified JSON.

The two directions solve different problems. Converting to YAML is usually about readability: config files, CI pipelines and Kubernetes manifests are written in YAML because indentation is easier to scan than nested braces. Converting to JSON is usually about compatibility, since most parsers, APIs and JavaScript code expect JSON. And because YAML is a superset of JSON, the YAML → JSON side doubles as a JSON formatter and minifier: paste JSON in and it validates and reformats cleanly.

How to convert JSON and YAML

1. Choose a direction. Use the JSON → YAML / YAML → JSON toggle above the input box to pick which way you are converting.
2. Paste your data and set the indent. Paste JSON or YAML into the input area, then choose an indent: 2 or 4 spaces when converting to YAML, or 2 spaces, 4 spaces, a tab or Minify when converting to JSON. If the input is invalid, the message underneath names the exact problem with its line and column.
3. Check the warnings and copy the result. The output appears in the read-only panel, and a warnings panel lists anything that could not be carried over unchanged. Copy takes the result, Clear resets everything, and the swap button sends the result straight back through the other direction.

What survives the conversion, and what doesn't

The most common way a JSON and YAML converter quietly corrupts data is the “Norway problem”: under the older YAML 1.1 rules, the bare word NO — the country code for Norway — is read as the boolean false, and yes, on and off get the same treatment. This tool parses with the YAML 1.2 core schema, where only true and false (in any capitalisation) are booleans, so country: NO stays the string “NO”, and yes, no, on and off all stay strings. The same schema keeps 12:30 as a string instead of the base-60 number YAML 1.1 would compute, and keeps 2024-01-15 as a string rather than promoting it to a date.

Numbers do lose one thing: how they were written. A YAML number becomes a plain numeric value, and a number has no memory of formatting, so 1.10 comes back as 1.1 and 0123 comes back as 123. That matters most for version strings — quote them in the source if you need the exact digits. Integers past about nine quadrillion (2⁵³) lose precision outright, because they cannot be held exactly: 12345678901234567890 comes out as 12345678901234567000. Rather than let that slip past in silence, this tool detects it and names the exact key it happened to, such as rows[0].id, showing both the original value and what it became.

Comments do not survive either, because JSON has no concept of them — the tool warns you when your YAML contained any, while correctly ignoring a # inside a quoted string and a #!/bin/sh shebang inside a literal block, neither of which is a comment. Anchors and aliases (an &defaults block reused via *defaults) are expanded rather than preserved: the content is duplicated everywhere it was referenced and the link between the copies is gone, which the tool also flags. Duplicate keys are rejected outright with the line number, since YAML forbids them and keeping the last one silently would hide a real bug in your file. A multi-document stream — sections separated by ---, common in Kubernetes manifests — is rejected with its own message, because JSON has no way to represent more than one document; convert them one at a time. Tab indentation is refused for the same kind of reason: the YAML specification does not allow it.

Going from JSON to YAML, the emitter protects you on the way out: it quotes any string a YAML 1.1 reader could misread, so “NO”, “yes”, “true”, “null”, “12:30”, “0123” and the empty string all come out quoted rather than bare. It even quotes a key named n, since a bare n would otherwise be read as false. Aside from the number cases above, a full round trip — JSON to YAML and back — was verified to return exactly the original data across about 2,000 randomly generated documents.

When you actually need this

YAML turns up wherever configuration has to be edited by hand: Kubernetes manifests, Docker Compose files, GitHub Actions and other CI pipeline definitions, and OpenAPI specifications are all commonly written in YAML but consumed by tools that speak JSON. Converting to YAML makes a JSON config easier to read and edit; converting back to JSON is what you want when the file has to be fed to a script, an API or a JavaScript object that only understands JSON — or when you simply want to check that a YAML config parses at all.

Why is it free?

The whole conversion runs in your browser. There is no server in the loop, nothing is uploaded and nothing is stored, so there is no per-use cost to pass on. That is also why there is no account, no sign-up, no watermark and no usage limit: paste, convert, copy.