Will strings like "true" or "123" stay strings?

Yes. Any JSON string whose text could be misread as a boolean, number, or null by a YAML parser - such as "true", "123", or "null" - is quoted in the output so it round-trips back to a string, not a different type.

How are multiline strings handled?

As double-quoted scalars with escape sequences, rather than YAML's block literal (|) or folded (>) styles. This keeps the conversion predictable and avoids subtle differences in trailing whitespace or line-fold behavior.

Does the output use anchors or aliases?

No. Even if the same object appears twice in your JSON, the YAML output repeats it in full rather than introducing an anchor and alias. That keeps the result easy to read and safe to edit without unexpected shared references.

What happens with a root-level primitive, like a bare number or string?

It's supported - the output is a single scalar document, such as just 42 or "hello", since YAML doesn't require a top-level mapping or sequence.

Why does my YAML have more lines than the original JSON?

YAML's block style puts each key or list item on its own line and uses indentation instead of braces and commas, so the same data naturally takes more lines. It's a tradeoff: more vertical space in exchange for structure you can see without counting brackets.

Browser tool Runs locally

JSON to YAML Converter

Convert JSON into clean, readable YAML without changing the underlying data. Runs locally in your browser.

JSON input

YAML output

YAML output will appear here.

What is JSON to YAML conversion?

JSON and YAML represent the same underlying data model - objects, arrays, strings, numbers, booleans, and null. Converting between them is a change of notation, not a change of meaning: the same values and structure come out the other side, just written with indentation and bare keys instead of braces, brackets, and quotes.

How to convert JSON to YAML

Paste JSON in the input panel.
Click Convert to YAML.
Copy or download as json-to-yaml.yaml.

Common use cases

JSON to YAML conversion comes up most often when moving data into a format meant to be hand-edited. Configuration files for tools like Docker Compose, Kubernetes, GitHub Actions, and Ansible are written in YAML, so an API response or a JSON config exported from one tool often needs converting before it fits into another. YAML is also common for CI/CD pipelines and application settings files, where comments and a cleaner visual structure make ongoing edits easier than they would be in raw JSON.

Readability and indentation

YAML drops the braces, brackets, and most of the quoting that JSON relies on, using indentation alone to show nesting. That makes a well-formed YAML file easier to scan - each level is visually offset - but it also means indentation is meaningful, not cosmetic: shifting a key by one space can move it into a different object entirely. This tool always produces consistent, correctly nested indentation, so the risk only appears if the output is edited by hand afterward.

Type differences and conversion surprises

JSON has a small, strict set of types, while YAML's parser tries to be more permissive about what counts as a boolean, number, or null - words like yes, no, on, off, and even country codes like NO can be read as booleans in some YAML parsers. To avoid this, strings that could be misread this way are quoted in the output. Numbers and booleans that are already typed correctly in the JSON are written unquoted, matching their type.

A practical example

A JSON object like {"name":"web","port":8080,"debug":false} becomes three plain lines in YAML - name: web, port: 8080, and debug: false - with no trailing commas or closing braces. Nested objects and arrays indent one level further instead of adding another set of brackets, which is usually where the readability gain is most obvious.

Common mistakes

Assuming YAML is always shorter - for deeply nested data, block-style YAML can end up with more lines than compact JSON, even though each line is simpler.
Hand-editing indentation inconsistently - mixing tabs and spaces, or shifting a key's indent level, silently changes which object it belongs to.
Expecting comments to survive a round trip - JSON has no comment syntax, so nothing is lost converting to YAML, but comments added to the YAML afterward will be dropped if it's converted back to JSON.
Forgetting that key order can matter to humans - JSON key order isn't semantically significant, but the converted YAML keeps the original order since it affects how easily the file reads top to bottom.

Frequently asked questions

Will strings like "true" or "123" stay strings?: Yes. Any JSON string whose text could be misread as a boolean, number, or null by a YAML parser - such as "true", "123", or "null" - is quoted in the output so it round-trips back to a string, not a different type.
How are multiline strings handled?: As double-quoted scalars with escape sequences, rather than YAML's block literal (|) or folded (>) styles. This keeps the conversion predictable and avoids subtle differences in trailing whitespace or line-fold behavior.
Does the output use anchors or aliases?: No. Even if the same object appears twice in your JSON, the YAML output repeats it in full rather than introducing an anchor and alias. That keeps the result easy to read and safe to edit without unexpected shared references.
What happens with a root-level primitive, like a bare number or string?: It's supported - the output is a single scalar document, such as just 42 or "hello", since YAML doesn't require a top-level mapping or sequence.
Why does my YAML have more lines than the original JSON?: YAML's block style puts each key or list item on its own line and uses indentation instead of braces and commas, so the same data naturally takes more lines. It's a tradeoff: more vertical space in exchange for structure you can see without counting brackets.