JSON to YAML converter

How the conversion works

Your text is parsed by the browser's own JSON parser and the resulting value is handed to js-yaml's writer, vendored on this site rather than fetched from a CDN. Everything JSON can express has a YAML equivalent, so no data is lost on the way across. All the interesting decisions are about presentation: how far to indent, when a value needs quotes, and where a long line may be broken.

Key order is preserved. The writer walks the object in the order the parser produced the keys, which is the order you wrote them, so a config file keeps its shape and diffs stay readable. Nothing is sorted alphabetically, nothing is added, and nothing is dropped. Nested arrays are indented under their key by the amount you choose — two spaces is the convention in Kubernetes manifests, GitHub Actions workflows and Docker Compose files, while four is more common in Ansible and in hand-written application configs.

Repeated values are always written out in full. YAML can name a value once with an anchor and refer to it later with an alias, and the library will do that by itself when it sees the same object twice; that behaviour is switched off here, because output littered with &ref_0 and *ref_0 is valid YAML that plenty of simple readers — and most people reviewing a pull request — do not expect.

Questions people ask

Why are strings like yes and no quoted in the output?

Because YAML 1.1 read them as booleans and plenty of parsers still do. The country code for Norway is NO, and a bare NO in a 1.1 file is the boolean false — which is why this is known as the Norway problem. The writer here follows YAML 1.2, where only true and false are booleans, but it still quotes yes, no, on, off, y, n and anything that looks like a number, so a file produced here cannot be misread by an older reader. That is why you get 'yes' rather than yes, and why a key named n comes out quoted as well.

How do nulls and empty strings appear?

A JSON null is written as the bare word null. An empty string is written as a pair of single quotes, '', because nothing at all after the colon would be read back as null — a different value entirely. Both survive a round trip unchanged, which is the point. YAML also accepts a tilde and an omitted value as null when reading, but only one spelling is produced here so the output stays predictable and diffs stay small.

What happens to a string containing newlines?

It becomes a block scalar, which is the readable form: the key, a pipe character, then the text indented underneath with no escaping at all. A string that ends in a newline uses a plain pipe; one that does not gets |-, the strip indicator, so the missing newline is not quietly added back when the file is read. Strings containing carriage returns, tabs or trailing spaces cannot be written as a block without ambiguity, so those fall back to a quoted single line with escape sequences.

Does the converter create anchors for repeated objects?

No. If the same object appears in three places it is written out three times. The library can emit anchors and aliases, and does so by default whenever it meets a value it has already serialised, but that option is turned off here. The result is longer and completely explicit, which is what you want when the YAML is going into a template, a cluster or a code review. If you want anchors, add them by hand — they are a convenience for people writing YAML, not something worth generating.

What does the line width option do?

It sets where long plain and folded strings may be broken across lines. At 80 characters a long value is folded onto continuation lines that a parser joins back together with spaces when it reads the file — the value is identical, only the layout differs. Choose no wrap and every value stays on one line however long it runs, which is what you want if a value has to be copied by eye or if a downstream tool diffs line by line. Block scalars and quoted strings that contain newlines are never folded either way.