Output appears here.
JSON to YAML converts a JSON document into clean, block-style YAML, quoting only the strings that would otherwise change type. It is for turning API output, OpenAPI specs or generated config into files people edit by hand, such as Kubernetes manifests and CI workflows. Conversion happens in your browser; nothing is uploaded.
How to convert JSON to YAML
- Paste JSON into the input pane, drop a
.jsonfile, or press ⌘/Ctrl O. The YAML appears as you type. - Choose an Indent of 2 or 4 spaces. If the JSON has comments or trailing commas, turn on Allow comments & trailing commas.
- Copy with ⌥/Alt C or download a
.yamlfile with ⌘/Ctrl S. Next actions open the result in the YAML Formatter or send it back through YAML to JSON to check the round trip.
Examples
OpenAPI fragment
A minified OpenAPI document. Keys that YAML would read as something else — "200" would become a number — are quoted automatically, as is the version string "1.0".
{"openapi":"3.1.0","info":{"title":"Orders API","version":"1.0"},"paths":{"/orders":{"get":{"summary":"List orders","responses":{"200":{"description":"OK"}}}}}}Result:
openapi: 3.1.0
info:
title: Orders API
version: "1.0"
paths:
/orders:
get:
summary: List orders
responses:
"200":
description: OKStrings that look like numbers or booleans
In JSON these are all strings. Written bare in YAML they would parse as a float, an integer, a boolean or a nested mapping, so the converter keeps them quoted.
{"version":"1.10","zip":"07302","enabled":"true","note":"a: b","empty":"","nothing":null,"tags":[]}Result:
version: "1.10"
zip: "07302"
enabled: "true"
note: "a: b"
empty: ""
nothing: null
tags: []Multi-line strings and nested lists, 4-space indent
A string containing line breaks becomes a readable | block instead of one line full of \n escapes.
{"script":"line one\nline two\n","items":[{"a":1,"b":[1,2]}]}Result:
script: |
line one
line two
items:
- a: 1
b:
- 1
- 2Options explained
- Indent — the number of spaces per nesting level in the YAML output, 2 or 4; list items are indented under their parent key.
- Allow comments & trailing commas — accepts JSONC-style input by removing comments and trailing commas before converting; without it, they are reported as errors.
Common conversion problems
The JSON does not parse
The converter needs valid JSON first. Errors show the line, column and a likely cause — trailing comma, single quotes, a missing comma. Fix the input here or in the JSON Validator, which offers an automatic fix.
Comments cause "JSON does not allow comments"
Files such as tsconfig.json or editor settings are JSONC. Turn on Allow comments & trailing commas. The comments themselves are dropped, since there is no reliable way to know where they belong in the YAML.
"NO", "yes" and "on" in older YAML readers
The output follows YAML 1.2, where NO, yes and on are ordinary strings, so they are written without quotes. Some parsers still apply YAML 1.1 rules and read them as booleans. If the file will be read by such a tool, quote those values after converting.
Large IDs change in another tool
The converter writes integers larger than 2^53, such as 12345678901234567890, with every digit. A program that later loads the YAML into double-precision numbers — JavaScript and many config loaders — may still round them. If the value is an identifier, store it as a string in the JSON so every reader keeps it exactly.
Numeric keys are quoted
Keys such as "2" or "10" keep their place in the original order and are written as "10": x. The quotes keep them strings; without them, a YAML reader would load them as numbers.
FAQ
Is it safe to convert config that contains secrets?
Yes. The conversion runs in your browser inside an isolated frame that blocks network requests, so connection strings, API keys and tokens in the JSON never leave your device and nothing is stored on a server. Settings are remembered on this device; the input is only kept if you turn on "Remember my last input".
Why are some values quoted and others not?
The converter quotes a string only when leaving it bare would change its meaning. "1.10" stays quoted because bare 1.10 is a number, and "a: b" because a bare colon starts a mapping. Plain words, paths and URLs are written without quotes, which is how people normally write YAML.
Can I add comments to the output?
Not during conversion, because JSON has no comments to carry over. Once the YAML is generated you can edit it and add comments freely. The YAML Formatter preserves comments when it re-indents a file, so later clean-ups will not remove them.
Does it produce flow style like {a: 1}?
No. Objects and arrays are written in block style — one key or item per line — which is easier to read and diff. Empty objects and arrays are the exception and appear as {} and []. If you prefer flow style for short lists, edit those lines by hand.
Will converting back give me the same JSON?
For data, yes: every string, number, boolean, null, object and array survives the trip, and YAML to JSON restores it. Key order and large integers are kept too; only whitespace and formatting differ. Use the Back to JSON action to check.
Should I use JSON or YAML for my config?
YAML is easier to read and allows comments, which is why Kubernetes and most CI systems use it. JSON is stricter, has fewer surprises and is native to JavaScript tooling. The guide JSON vs YAML compares them in detail, including the implicit-typing traps shown above.
Related tools
Before converting, format and check the JSON to spot structural problems. For Rust and Python project files, JSON to TOML produces TOML instead. Every converter is listed under data tools.
Related tools
Guides
- JSON vs YAML: When to Use Which — When should I use JSON and when YAML?