Converters

JSON to YAML Converter

Convert JSON to YAML in your browser — paste JSON or drop a .json file to get indented, readable YAML back without an upload to a server.

JSON

Paste JSON above, drop a .yaml, .yml or .json file anywhere on this panel, or .

This page runs the converter in the opposite direction from its parent: paste or drop JSON and get back indented YAML, rather than the other way round. The interesting decisions in this direction aren't about parsing — JSON is unambiguous going in — they're about how a JSON value gets written as YAML, since YAML gives you more than one way to spell almost everything.

YAML's indentation rules, and what decides them here

Everything nested in your JSON — every object inside an object, every array inside an object — becomes an indented block in the output, with each level stepped in by either 2 or 4 spaces depending on which you pick from the Indent selector. That selector only offers those two options here, not a minified third one: YAML has no minified form at all, since a bare block without line breaks or indentation isn't valid YAML the way a JSON object squeezed onto one line is still valid JSON. If you're used to the JSON side's Minified option, its absence on this page isn't a bug — it's YAML's own syntax rejecting the idea.

Why some values are bare and others are quoted

The rule this converter follows is symmetric with how its own YAML reader interprets a bare value: a string is left unquoted unless writing it bare would make it read back as something else. A word like staging needs nothing around it. A value that looks like a number, starts with -, #, &, * or another character YAML treats structurally, contains a colon followed by a space, or would otherwise resolve to true, false or null if left bare, gets wrapped in double quotes instead. The result is that nothing quoted here needed to be, in the sense of changing meaning if left plain, and nothing left bare is silently ambiguous.

Multi-line strings: quoted, not a block scalar

YAML's literal (|) and folded (>) block styles are the usual way a human-written YAML file holds a multi-line string, and this converter's YAML → JSON side reads both correctly when it finds them in a document you paste. Generating one on the way out, though, means choosing indentation, line wrapping and a chomping indicator with no single correct answer for an arbitrary string — so a multi-line value in your JSON instead comes out as a double-quoted YAML string with its line breaks written as \n, exactly the way JSON itself represents them. It's less pretty than a block scalar, but it's unambiguous and it survives being converted back without any decision this tool would have to guess at.

The Norway problem, solved on the way out

no, yes, on and off are always quoted in the output, even though this tool's own reader already treats them as plain strings. That asymmetry is deliberate: older, YAML 1.1-following readers treat those same bare words as booleans, so a country code of "NO" written out unquoted would round-trip fine through this tool and then silently become false the moment it hit a different, older YAML parser somewhere downstream in a pipeline. Quoting them here closes that gap regardless of what reads the file next.

Where this direction actually gets used

JSON to YAML mostly comes up when a config format wants YAML but the data started life as JSON — an API response being turned into a Kubernetes manifest fragment, a JSON payload being pasted into a CI pipeline's environment block, or a JSON export from one tool needing to become the input format another tool expects. Nothing pasted or dropped here is uploaded anywhere; it's converted entirely inside this browser tab, the same as the YAML → JSON direction on the parent page.

Questions

Why does my multi-line JSON string come out as a quoted line instead of a YAML block scalar?
Because this converter writes a multi-line value as a double-quoted string with its line breaks escaped as \n, the same way JSON itself would write it, rather than reformatting it into YAML's literal (|) or folded (>) block style. Block scalars are a real part of YAML and this tool's YAML → JSON side reads them correctly when they show up in a document you paste in — but generating one on the way out means deciding how to wrap long lines and which chomping indicator to use, choices with no single right answer that would make the emitted file harder to predict. A quoted string with escaped newlines is unambiguous and round-trips perfectly; it just isn't as pretty on the page as a block scalar would be, so a multi-line description or script embedded in your JSON will come out readable but not reformatted.
Why did some of my string values get wrapped in quotes when others didn't?
A plain, unquoted word in YAML gets read back according to a specific set of rules — certain words become booleans or null, certain patterns become numbers — and this converter only quotes a value when leaving it bare would trigger one of those rules and change its meaning. An ordinary word like `staging` or `production` comes out bare because nothing about it looks like anything other than a string. A value like `123`, `true`, `null`, or one starting with a character YAML treats specially, like `-` or `#`, gets quoted specifically so it converts back to the same string rather than silently becoming a number, a boolean or a comment. The rule is symmetric with how this tool's own YAML reader interprets a bare value, so nothing quoted here would have come back wrong if left plain, and nothing left bare is actually ambiguous.
Will a country code like NO turn into a boolean when I convert JSON to YAML?
No — and this is the one case this converter goes out of its way to protect against. Older YAML readers, following the YAML 1.1 spec, treat the bare words yes, no, on and off as booleans, which is why a country code field holding the string "NO" can silently become the boolean false in some tools — a real, well-known failure case for anyone piping YAML through mixed tooling. This converter always wraps those specific words in quotes on the way out, specifically so a YAML 1.1 reader downstream still sees a string rather than a boolean, even though this tool's own reader already treats them as strings when left bare.
Why do empty objects and arrays come out as {} and [] instead of an indented block?
Because YAML's indented block style has no way to represent nothing — a mapping key with no lines under it just reads as a key with a null value, not an empty object, so an empty {} or [] has to be written using YAML's flow style instead, on the same line as the key. Every other object and array in your JSON converts to YAML's normal indented block layout; empty collections are the sole exception, and it's a structural one rather than a stylistic choice.
What happens to JSON's null when I convert it to YAML?
It becomes the bare word null. YAML has more than one way to spell a null value — a bare tilde (~) is the terser, more traditional option some tools default to — but this converter always writes the word out in full, since it reads unambiguously to anyone unfamiliar with YAML's shorthand and is what most hand-written YAML in the wild already uses. Converting that YAML back to JSON on the parent page turns it back into JSON's own null exactly, with nothing lost in either direction.