YAML to JSON Converter

There are two YAML schemas, and they disagree

This page uses **YAML 1.2, core schema**. That is a choice, and it changes what your file means. YAML 1.1 — the older specification, still what a great deal of deployed configuration tooling implements — reads several very common values differently.

The first row is the Norway problem, and it is worth dwelling on because it is a country code that becomes a boolean. Everything else has the same shape: the file is fine, both parsers are correct, and the two disagree about what it says.

Quoting settles it

Every row above is about an *unquoted* value, because that is where a parser has to infer. `'012'`, `"1_000"` and `'no'` are strings under both schemas — the quotes are an instruction, and both parsers follow it. This page does not warn about quoted text, and if you are writing a file that more than one tool will read, quoting is the fix that costs nothing.

The rules behind the table are not what you would guess

Two of these are the kind of detail that is easier to measure than to remember, and this project measured them because the first attempt at writing this table got both wrong:

• YAML 1.1's float pattern needs a decimal point **and** a signed exponent. `1.5e-3` is a number; `1.5e3` is text; `1e3` is text. Both, not either.
• The base prefixes run in opposite directions. YAML 1.2 has `0o` and `0x` and no `0b`. YAML 1.1 has `0b` and `0x` and no `0o`.
• Digit separators exist in 1.1 and not in 1.2's core schema, so `1_000_000` is a number to one and a string to the other.

What the conversion changes without saying so

These are not schema differences. In every case the output is correct JSON, the value has genuinely changed, and nothing in the output indicates it. This is the reason the page shows a list rather than just a result:

The `.nan` case is the sharpest one. JavaScript has a real `NaN`, and `JSON.stringify` writes it as `null` without complaint. The JSON is valid. The value is destroyed. And a reader of the output has no way to tell that null from a null you wrote on purpose.

The boundary, because a check without one is just noise

This page does **not** warn about float precision. `0.1` has no exact binary representation, strictly, so in that sense every float is imprecise, and detecting it honestly would need exact decimal arithmetic that fires on values which round-trip perfectly. So it is not reported.

What *is* reported is the two unambiguous cases: a value that is not finite, and a non-zero literal that became zero. And the integer check has a boundary in both directions — `9007199254740991` is the largest integer a JavaScript number holds exactly and this page says nothing about it, while `9007199254740992` is the next one up and is also exact, and the first that is not is `9007199254740993`.

Going the other way is safer, and still not lossless

JSON to YAML is the comfortable direction, because JSON is a subset of YAML 1.2 — every JSON document is a valid YAML document, and every value keeps its type. The strings that look like other types are quoted on the way out, which is the whole job:

{ "a": "1", "b": "true", "c": "null", "d": "no" }

One thing this page does that a `JSON.stringify`-based converter cannot: it keeps your key order. `{"2":"b","1":"a"}` comes out as `2` then `1`, not the other way round.

The reason is worth knowing, because it will bite you somewhere else. JavaScript hoists integer-like keys on **every** object, so `JSON.parse` has already thrown your order away by the time any code sees it. The page reads the source with an order-preserving parser instead — the same one the JSON Formatter uses — and rebuilds the document in the order you wrote it.

Things this page refuses

A converter that cannot fail is not a converter, it is a formatter with opinions. Three refusals, each for the same reason — the alternative is a result that looks right and is not:

• **A file with more than one document.** A Kubernetes manifest is a `---`-separated document stream, and converting the first and dropping the rest hands back a file that parses and is missing most of its content. The page says how many documents there are and converts none of them.
• **Duplicate keys.** A YAML 1.1 parser keeps the last value and says nothing, so a file that sets `image:` twice quietly resolves the other way round. This page stops.
• **A file whose anchors multiply.** Anchors expand exponentially — each level repeats the last by some factor — so a small file can be a denial of service. It is refused, with a message about what happened rather than a claim that you tried to attack it, because almost every file that trips this is somebody's workflow multiplying by accident.

Merge keys are the near miss. A `<<` key is not resolved here: it is left as a literal key called `<<` holding the mapping it pointed at, so a child does not gain its parent's keys. A 1.1 parser would have merged them. The page reports it rather than quietly doing either thing.

On round-tripping

You will see converters advertise that a value survives a round trip. For the JSON-native subset that is very nearly true, and "very nearly" is doing real work in that sentence: the formatting changes, the line endings change, and a comment does not come back at all, because JSON has nowhere to put one.

For anything using YAML's own features it is often simply false. `.nan` does not come back. A `!!set` does not come back. A key of `1` comes back as the string `"1"`. If you need a round trip to be exact, keep the original — which is the advice this page can give without needing to be clever, and the reason it never offers to overwrite anything.

What it runs on

One dependency: the `yaml` package, which has no dependencies of its own. Hand-rolling a YAML parser was never a serious option — the grammar is large, and a partial implementation accepts what it understands and mishandles the rest, which is worse than having none.

The behaviour described on this page was checked against **PyYAML**, an independent YAML 1.1 implementation, in the project's test suite. That is what makes the 1.1 column above a measurement rather than an assertion — and it is what caught three errors in the first draft of this table.