YAML swaps punctuation for whitespace
Both formats describe the same three things: mappings, sequences, and scalars. JSON marks the boundaries with braces, brackets, and commas, so a file survives being flattened onto one line. YAML marks them with indentation and a dash, so the shape of the file is the data. Every brace you delete moves meaning into a column position.
{"service": {"port": 8443,"regions": ["eu-west-1", "us-east-2"]}}service:port: 8443
regions:- eu-west-1
- us-east-2Two practical consequences follow. Tabs are illegal as indentation anywhere in a YAML document, so an editor set to hard tabs breaks the file the first time somebody adds a line by hand. And a stray space in front of a key reparents it under the previous entry without any error, because the result is still a legal document, just a different one. The output here uses spaces only and keeps the indent constant at whatever the control is set to.
The quoting question, and why NO turns into false
This is the failure that costs people an afternoon. YAML 1.1, published in 2005, resolved a long list of bare words to booleans: y, yes, on, true, and their negatives. YAML 1.2 dropped all of them except true and false. Plenty of live parsers still run 1.1 rules, including PyYAML in its default configuration and the Ruby standard library, so a country list written with Norway in it becomes a list with false in it.
| Your JSON string | Bare in YAML 1.1 | Where this bites |
|---|---|---|
"NO" | false | ISO country codes, Norway and Nigeria both affected |
"on" / "off" | true / false | Feature flags and switch labels stored as words |
"0755" | 493 | File modes, a leading zero reads as octal |
"12:30" | 750 | Times and durations, colons read as base 60 |
"1.20" | 1.2 | Version numbers, the trailing zero is gone |
"null" | ~ | Literal placeholder text that becomes an absent value |
Leave YAML 1.1 safe quoting ticked and every token in that table ships wrapped in quotes, which holds it as a string under both specification versions. Untick it and the boolean words and the sexagesimal times go bare, which is shorter to read and correct when you know the consumer is a 1.2 parser such as Go's yaml.v3 or JavaScript's js-yaml.
Two rows behave the same either way. A leading-zero string like 0755 and a decimal like 1.20 stay quoted in both modes, because those read as numbers under YAML 1.2 as well, and dropping the quotes would corrupt the value for every parser rather than only the old ones. That is why the panel under the converter reports each token as Bare or Quoted against the YAML actually sitting in the right pane, instead of assuming the switch settles it. The 1.1 traps tile counts the distinct tokens found, and the panel lists up to ten of them.
Quote every string is a different setting
The Quote every string switch is blunt by design. It puts double quotes around all text values, including plain words that need no protection. Output gets noisier, and diffs get larger, but ambiguity drops to zero. Reach for it when the YAML feeds a parser you have never tested, or when a config repository has already been bitten once and the team wants a rule instead of a judgment call.
Line breaks turn into block scalars
A JSON string holds newlines as the two characters \n. YAML writes real line breaks instead, using a block scalar marked with a pipe. That is far easier to read, and it changes what a diff looks like when somebody edits one sentence in a long description.
{"readme": "First line.\nSecond line."}readme: |-
First line.
Second line.The - after the pipe is the chomping indicator. It says the value ends after the last visible character with no trailing newline, which matches what the JSON string actually contained. A bare | would add one newline at the end and |+ would keep all of them. Getting this wrong is how a copied SSH key or certificate stops validating, so the exact marker matters more than it looks.
The Line width control governs when long single line strings get folded across several lines. Set it low and the file becomes a narrow column that survives side by side code review. Set it to 200 and most values stay on one line. Folding never changes the value, because YAML rejoins folded lines with a space when it reads them back.
Flow style, for the parts that read better inline
Block style is the default and is what people picture when they picture YAML. Flow style is the JSON-shaped alternative, and YAML accepts it because JSON is a valid subset of YAML 1.2. Mixing the two is normal in hand written config, where the top of the tree is spread out and the leaves are compact.
limits:cpu:- 100m
- 500mlimits: {cpu: [100m, 500m]}Pick the level where detail stops mattering. A manifest with fifty short label pairs reads better with those pairs inline and the structure above them expanded. Going fully inline defeats the point of converting at all, since the result is close to the JSON you started with.
What the counters are telling you
- Max depth is nesting levels in the source data. YAML gets visually hard to follow past six or seven, because the reader has to count columns. Deep API responses often want restructuring rather than conversion.
- Keys counts every mapping key including repeats inside arrays, which is the number that drives file length more than the value sizes do.
- 1.1 traps is the count of distinct strings that change type when written bare. Zero means the document is safe under either specification version.
- Size change compares bytes against the JSON you pasted. YAML usually comes out 10 to 25 percent smaller, since it drops braces, brackets, commas, and the quotes around keys. Turn on Quote every string and the saving mostly disappears.
Sorting keys changes more than the order
Ticking Sort keys alphabetises every mapping at every level. That makes two generated files comparable, which is the reason it exists: a diff between yesterday's export and today's stops being noise the moment both are sorted. The cost is readability. A Kubernetes manifest with apiVersion and kind at the top is following a convention, and sorting pushes apiVersion above kind while dropping spec and metadata wherever the alphabet puts them. Sort machine to machine files. Leave files a person maintains alone.
Anchors and aliases will never appear in this output, and that is not a missing option. YAML deduplicates repeated structures with an anchor such as &defaults and a reference such as *defaults. Those exist in the document object graph, not in the text. Parsing JSON produces a fresh object for every brace, so nothing in the tree is shared and there is nothing to anchor. If your config repeats the same block six times and you want one definition with five references, that restructuring happens in the YAML by hand. No converter can infer it, because the JSON never recorded that the six blocks were meant to be the same thing.
Where this page stops
Comments are not generated, since JSON has nowhere to store them. If the YAML you are producing replaces a file that had comments, copy them across before you commit, because a comment-free config is the most common regression from an automated conversion.
Multi-document output is not supported either. YAML separates documents with --- between them, and Kubernetes users often keep several resources in one file. The Start with --- switch adds a single opening marker for tools that expect one, and no more than that. Split the resources yourself, or convert them one at a time.
Custom tags such as !!binary, dates as real timestamp nodes, and complex keys are all outside what JSON hands over. A date in JSON is a string, so it stays a quoted string here rather than becoming a YAML timestamp. Some parsers accept the string and coerce it later, others need the tag, and guessing which would break more files than it fixes.
Conversion runs entirely in this tab through js-yaml. Nothing is uploaded, so a manifest with real secrets in it stays on your machine, and nothing survives closing the tab. Very large files, past a few megabytes, will make the editors sluggish before the conversion itself becomes the problem.
Pages for the neighbouring jobs
Coming back the other way is handled by YAML to JSON. If the YAML you produce here gets rejected downstream, the YAML validator reports the line and the reason. When the JSON refuses to parse before you get this far, run it through the JSON fixer first, since this page reports the error position and leaves the repair to you. For a document format rather than a config format, JSON to XML covers that side, and the YAML cheat sheet is worth a look when the block scalar markers stop making sense.
