JSON to YAML
JSON to YAML converts a document to YAML in your browser and verifies the result by parsing it back. The rule that makes that work: a string is quoted whenever writing it bare would resolve to something else — so the string "no" keeps its quotes, and so do "007", "null" and "12:30".
How does JSON to YAML work?
Going from JSON to YAML sounds like the easy direction — YAML is a superset, so every JSON document is already valid YAML. That is true and it is not the job. The job is to produce YAML a person would want to read, which means block style rather than flow style, and that is where the correctness problem appears.
Quoting is not cosmetic
YAML resolves unquoted scalars by pattern. Write the string no without quotes and a YAML 1.1 reader loads the boolean false. Write 007 and you get the number 7. Write null, true, 12:30, 0x1f or .inf and each comes back as something that is not a string.
So the emitter runs the resolution rules in reverse: a string is quoted whenever writing it bare would resolve to anything other than that string. It also quotes the tokens that 1.1 would resolve differently even though 1.2 would not, because the output should mean the same thing wherever it is read. This is why the result has quotes in places that look unnecessary — every one of them is load-bearing.
The round trip is checked, not claimed
Every conversion is parsed back and compared against the original JSON, and the result is reported in the stats strip. A quoting rule that misses one case is exactly the kind of bug that produces plausible output and a corrupted config, so the check runs on your document rather than only in a test suite.
Multi-line strings become block scalars
A string containing newlines is written as a | block, which is the reason people put certificates, scripts and SQL in YAML instead of JSON: a PEM key in JSON is one unreadable line of \n escapes. The chomping indicator follows the data — | when the string ends with a newline, |- when it does not — so the trailing byte survives.
Keys are quoted by the same rule as values
A key is a scalar too. y: 2 loads as {True: 2} in a 1.1 reader, and on: — the second key of every GitHub Actions workflow — is the best-known example. Keys get the same treatment as values, which is why "on" comes out quoted.
JSON
{
"regions": ["NO", "SE"],
"build": "007",
"enabled": true
}YAML
regions: - "NO" - "SE" build: "007" enabled: true
What options and edge cases does JSON to YAML support?
| Parameter | Type | Default | Behaviour & edge cases |
|---|---|---|---|
| Indent | spaces | 2 | Spaces per level. YAML forbids tabs in indentation entirely, so this is a count and not a character. |
| Indent sequences | boolean | off | Off puts list dashes at the parent key's column, which is what hand-written Kubernetes manifests look like. On indents them one level, which is what most libraries emit. Both are valid. |
| Sort keys | boolean | off | Alphabetical rather than document order. Useful for diffing two configs that were written in different orders. |
| Document start | boolean | off | Emits the --- marker. Required when concatenating several documents into one file, as Kubernetes manifests usually are. |
| Ambiguous strings | quoted | always | no, yes, on, off, y, n, true, null, ~, 007, 12:30, 0x1f, .inf and the empty string. Each would resolve to a non-string if written bare. |
| Multi-line strings | block scalar | on | Written as a | block, with the chomping indicator matched to whether the string ends in a newline, so no byte is added or lost. |
| Empty containers | [] and {} | explicit | An empty array or object is written in flow style. Omitting them entirely would make an empty list indistinguishable from a null. |
| null | null | null | Written as the word null rather than left empty or written as ~, because it is the spelling that reads the same to a person and to every parser. |
| Round trip | verified | every conversion | The output is parsed back and compared to the input. The result is reported in the stats strip rather than assumed. |
Frequently asked questions
Why did it put quotes around my ordinary-looking string?
Because writing it bare would resolve to something else. "no" becomes the boolean false in a YAML 1.1 reader, "007" becomes the number 7, "12:30" becomes a sexagesimal number, and "null" becomes null. The quotes are the only thing keeping the value a string, which the round-trip check in the stats strip confirms on your actual document.
Is YAML really smaller than JSON?
Usually, and the stats strip shows the number for your document. Dropping braces, brackets and the quotes around keys removes a surprising fraction of a config file. What YAML buys over JSON is not size, though — it is comments, which JSON has no way to express at all, and readable multi-line strings.
Can I get my comments back?
No, and nothing can. JSON has no comments, so by the time a document is JSON the comments are already gone — there is nothing in the input to recover. If you are editing a YAML file, edit the YAML: a JSON round trip strips every comment and reorders nothing back.
Which list style should I use?
Either; they parse identically. Dashes at the parent key's column is what hand-written Kubernetes manifests and GitHub workflows look like, and it saves two columns of indentation on deeply nested files. Indented dashes is what most libraries emit and what some house styles require. Pick the one that matches the files around it.
Why is my multi-line string not escaped like it was in JSON?
Because it is written as a | block scalar, which keeps real line breaks instead of \n escapes. This is the single best reason to use YAML for a config file: a PEM certificate or a shell script is readable in YAML and is one 3,000-character line in JSON. The chomping indicator is chosen to preserve whether your string ended with a newline.
Is my JSON uploaded?
No. The parse, the conversion and the verification round trip all run in your browser. You can confirm it in the Network panel. It matters here because JSON being converted to YAML is usually about to become a config file, and config files carry connection strings and keys.