YAML to JSON Converter

This is the lossy direction, and it is lossy in ways that are easy to miss. YAML is a superset of JSON, so going the other way discards whatever YAML could express that JSON cannot: comments, anchors and aliases, multi-document streams, explicit type tags, non-string mapping keys, and the distinction between the three ways of writing a multi-line string. The data survives; the authoring information does not.

That is usually fine, because the reason to convert is almost always to feed the data to something that speaks JSON — a jq pipeline, an API request body, a JSON Schema validator, a test fixture, or a language whose YAML library you would rather not add as a dependency. The parser here is YAML 1.2 compliant and runs in a Web Worker in your browser, so nothing is uploaded.

What YAML has and JSON does not

Comments are dropped. JSON has no comment syntax, so every # line disappears. In configuration this is often the most valuable content in the file — the note explaining why a timeout is 75 seconds, the owning team's email address, the "do not raise this above 4" warning. Keep the YAML as your source of truth and treat the JSON as a derived artefact, never the other way round.

Anchors and aliases are expanded, not preserved. An anchor &defaults referenced later as *defaults, or merged in with <<: *defaults, is resolved during parsing. The JSON contains a full copy of the block at every point it was referenced. The data is correct, but the file gets larger and the intent — "these are deliberately the same" — is gone. Edit the JSON in two places and they silently diverge.

A multi-document stream becomes a JSON array. JSON has one value per document, so a stream with two documents separated by --- converts to a two-element array, one element per document. A single-document file converts to that document's value directly, not to a one-element array. Check which shape you got before writing code against it.

Explicit tags lose their meaning. A value tagged !!binary, !!timestamp or with a custom application tag becomes an ordinary JSON string or object. The tag is not represented.

Non-string keys are coerced. YAML allows a mapping key to be a number, a boolean, or even a whole sequence or mapping. JSON object keys must be strings, so anything else is stringified. Complex keys — the ? key form — cannot be represented meaningfully at all.

Block scalar style is lost. The literal | and folded > forms produce different strings, and whichever string results is what lands in the JSON, correctly. But the JSON just holds a string with \n escapes; nothing records which style produced it, so a round trip back to YAML will pick the emitter's preference rather than yours.

Implicit typing, and the Norway problem

YAML infers types from the shape of unquoted scalars, and this is where converted data most often goes wrong. The infamous case is the ISO country code for Norway: in YAML 1.1, unquoted NO is the boolean false. A list of country codes written naturally as [GB, FR, NO, SE] silently becomes ["GB", "FR", false, "SE"]. The same applies to yes, no, on, off, y and n.

The parser used here follows the YAML 1.2 core schema, where only true and false are booleans, so NO and no stay strings. That is the modern, correct behaviour — but it also means this converter and an older YAML 1.1 tool such as a legacy PyYAML setup will disagree about the same file. If the JSON you get here does not match what your Python script produces, this is very likely why.

Other implicit typing traps worth checking in the output: a version string such as 1.10 unquoted becomes the number 1.1 and loses the trailing zero; a build number such as 0755 is read as a number under some schemas; a MAC address or time value such as 12:30:00 was sexagesimal in YAML 1.1; and a bare ~ or an empty value is null.

The fix in every case is the same and it belongs in the YAML, not in the conversion: quote scalars whose string-ness matters. Version numbers, country codes, phone numbers, postcodes, port lists and anything with a leading zero should be quoted at the source.

Duplicate keys and other silent hazards

YAML permits a mapping to contain the same key twice. Most parsers accept it and the last occurrence wins, which is exactly the behaviour that hides a merge conflict resolved badly. JSON object keys are also last-wins in practice, so the duplicate simply vanishes during conversion without comment. If you suspect a file has duplicates, run it through the YAML validator first, which reports them explicitly.

Very large integers are another edge. YAML can express an integer of arbitrary size, while JSON numbers are IEEE-754 doubles in every mainstream implementation, so anything beyond about 9 quadrillion loses precision. Snowflake IDs and 64-bit database keys are the usual victims; quote them as strings in the YAML if they must survive intact.

Everything runs locally in a Web Worker. Configuration files are precisely the sort of document that contains internal hostnames, service account names and occasionally a secret that should not have been committed, and none of it is transmitted anywhere by this page.