JSON to YAML, with the strings YAML would misread quoted for you

Start with the JSON array ["MY","SG","NO","ID"] — four country codes. Written into YAML without quotes, the third one is no longer the text NO. YAML 1.1 resolves an unquoted no, in any capitalisation, to the boolean false, so the list arrives at the other end with false where Norway used to be, and nothing along the way reports a problem. It is not only NO: yes, no, on, off, true and false are all booleans in YAML 1.1, which is exactly why a config line like enabled: on works at all. Paste that array into the box above and you will see "NO" come back quoted while MY, SG and ID stay plain.

Everything YAML would read as something other than text. The empty string, null and ~ all read as null. The boolean words above, plus a bare y or n, which some parsers also treat as booleans. Anything that reads as a number — and YAML’s idea of a number is wider than JSON’s: 017 is 15 (octal), 0x1F is 31, 1_000 is 1000, and 1:30 is 90, because YAML 1.1 reads colon-separated digits as base sixty, which quietly turns durations and times into integers. A date shape such as 2026-08-10 comes back as a date object rather than a string. Then the layout hazards: leading zeros, leading or trailing spaces, a first character from the indicator set - ? : , [ ] { } # & * ! | > ' " % @ `, a colon followed by a space, and a space followed by #, which starts a comment. Quoting more than strictly necessary costs nothing, because a quoted string reads back as the same string; missing one changes its type.

Because in your JSON it was a string. Unquoted in YAML it comes back as the float 1.0, which most tools then print as 1 — so a version pinned to 1.0 becomes 1 and stops matching anything. The rule throughout is that a JSON string stays a string and a JSON number stays a number. That cuts both ways: if you write {"a": 1.0} as a real JSON number, it is emitted as a: 1, because 1.0 and 1 are the same number and that is its canonical form. A related case worth knowing: 1e5 is a number in YAML 1.2 and a plain string in YAML 1.1, so quoting it is what makes it mean the same thing in both.

Because folding changes the text. A folded scalar joins single line breaks into spaces when the file is read back, so a two-line string written with > returns as one line with a space in the middle. The literal style, |, keeps every break exactly. Multi-line strings therefore get | when the text ends in a newline and |- when it does not — the dash strips the trailing newline that a block would otherwise add. Where neither can be exact, because a line ends in a space, or the first line starts with one, or the text ends in more than one newline, it falls back to a double-quoted string with \n escapes. > is a reasonable thing to choose by hand for prose you wrote yourself; it is not something a converter can choose on your behalf for data it has never seen.

No, and that is the design rather than a gap. Reading YAML means implementing anchors, aliases, tags, flow style, multiple documents per file and several type-resolution schemas that disagree with each other — thousands of lines that all have to be right, or somebody’s config breaks in a way they will not notice until deployment. Writing YAML from JSON means the values have already been decided by the JSON parser, and the only remaining job is writing them so that a YAML parser reads the same thing back. Half the work and twice the confidence, so this page does one direction properly instead of two badly. If what you actually need is to check that your JSON is valid or to explore it as a tree, the JSON formatter on this site does that.

Either width is fine; two is the convention in almost every config format that uses YAML, and four is easier to follow when the file nests deeply. Tabs are not offered because YAML forbids a tab character in indentation, full stop. Pasting one in gives a parse error that is famously hard to see, since the file looks perfectly aligned in an editor that renders tabs as spaces. One other detail of the layout: list items always sit two characters after their dash whatever the indent width, because “- ” is two characters wide and the first key of an item has to line up with the column immediately after it.

None of them appear, because none of them exist in the input. JSON has no comments, so there are none to carry across — this is also why converting in the other direction is lossy, and why nobody should round-trip a hand-written config through JSON. The same goes for anchors and aliases (&name and *name), which let a YAML file define a block once and reuse it, and for the --- marker that separates several documents in one file. You get one document, written out in full, with repeated data repeated. Key order follows your JSON, with one exception JavaScript imposes: keys that look like non-negative integers, such as "2" and "10", are ordered numerically ahead of the rest no matter how you wrote them.

Both, by aiming at the stricter reading. YAML 1.2, published in 2009 and revised in 2021, cut the list of words that resolve to booleans down to true and false and made the format a superset of JSON. YAML 1.1, from 2005, is the older and looser one — and it is still what PyYAML implements, which means a large amount of Python tooling reads your file that way. So this emitter quotes anything either version would misread. The output carries slightly more quotation marks than a 1.2-only tool would produce, and in exchange the same file means the same thing whichever parser opens it.

No. Parsing and emitting both happen in this page, there is no request of any kind, and nothing is written to localStorage, so closing the tab leaves nothing behind. It is worth stating on this page in particular: a JSON blob on its way into a config file very often carries a hostname, a bucket name, an internal path or a connection string.