YAML to JSON Converter

YAML 1.1 resolves an unquoted yes, no, on, off, true or false — in lower case, title case, or upper case — to a boolean. YAML 1.2 cut the list down to true and false. Nothing obliges a library to follow the newer spec, so the answer depends entirely on which one your parser implements, and both are still in wide use.

The numbers are easy to check. yaml.safe_load("country: NO") in PyYAML 6 returns {'country': False}. The same input through js-yaml 4, which this page uses, returns the string "NO". One YAML file, two JSON documents, and no warning from either side. A list of country codes containing Norway is the canonical case that gave the bug its name, but a column of y/n flags, a chemical formula, or a config key literally named off will do it just as well.

The fix is quoting at the source: country: "NO". When you cannot edit the file, at least choose the parser deliberately rather than inheriting whichever one your language ships with, and pin the schema in code so an upgrade cannot change your data.

The YAML 1.1 integer resolver is generous, and PyYAML implements it faithfully. A leading zero means octal, so mode: 0644 loads as 420 — while js-yaml, reading the same line under the 1.2 core schema, gives you the decimal 644. Two parsers, two file permissions, no error either way. Only 0o644 means 420 in both.

Colon-separated digits are base 60 under 1.1, a feature dropped from 1.2 precisely because nobody wanted it. duration: 1:30 becomes the integer 90 in PyYAML and stays the string "1:30" in js-yaml. Hexadecimal is consistent but no less lossy: 0x1F is 31 in both, so an identifier that happens to look hexadecimal reaches your JSON as a number with its original spelling gone.

Two more do not survive the JSON step at all. .inf and .nan are YAML floats with no JSON literal: JavaScript writes them as null, and Python writes bare Infinity and NaN, which is not valid JSON and will be rejected by strict parsers downstream — pass allow_nan=False to json.dumps if you would rather have the exception now. And large integers are quietly rounded: id: 12345678901234567890 comes out of a JavaScript toolchain as 12345678901234567000, because anything past 2^53 − 1 cannot be held exactly in a double. Quote your identifiers and keep them strings end to end.

YAML 1.1 defines a timestamp type, and both major parsers implement it, so an unquoted date is never a string by the time serialisation begins. In PyYAML, released: 2024-01-15 becomes a datetime.date, and the conversion then fails at the JSON step rather than the YAML one, with TypeError: Object of type date is not JSON serializable. If you meet that error while converting a config, an unquoted date is why.

JavaScript does not fail; it changes your value. js-yaml resolves the same line to a Date, and JSON.stringify renders a Date as an ISO instant — so the converter above turns released: 2024-01-15 into "2024-01-15T00:00:00.000Z". A calendar date has silently acquired a time and a UTC offset it never had, which matters the moment someone in UTC+05:30 formats it back for display and sees the previous day.

The type resolution is also narrower than it looks, which makes the damage patchy. 2024-01 does not match the timestamp pattern and stays a string, while 2024-01-15 on the very next line does not. You end up with a JSON document where two adjacent version fields have different types. Quote anything you want to remain text, and serialise deliberately — default=str in Python, or a replacer in JavaScript — when you want the ISO form.

The spec says keys in a mapping must be unique; enforcement is a library decision. PyYAML accepts a duplicate without complaint and keeps the last occurrence, so a: 1 followed by a: 2 loads as {'a': 2}. js-yaml raises a YAMLException reading duplicated mapping key. A file where someone appended a second image: at the bottom of a 300-line manifest therefore works in one CI runner and fails in another, which is a genuinely difficult afternoon.

The loss is invisible after conversion, because JSON behaves the same way: RFC 8259 says names should be unique and leaves duplicates undefined, and JSON.parse keeps the last. Nothing in the pipeline will ever tell you a value was overwritten, so the only reliable check is on the YAML side, before conversion.

Tabs are the other one. YAML forbids tab characters in indentation outright — they are legal inside scalar content and as separation in flow context, but never as structure. PyYAML reports found character '\t' that cannot start any token; js-yaml says tab characters must not be used in indentation. An editor that inserts a real tab on autocomplete produces a file that is visually identical in a diff viewer and refuses to load, and cat -A, which prints tabs as ^I, is the fastest way to find it.

Anchors are expanded, not preserved. Three aliases to a 200-line block become three full copies, so a 4 KB YAML file can convert into a JSON file two orders of magnitude larger that is correct and unmaintainable. A recursive anchor — a node aliasing one of its own ancestors — cannot be expanded at all: the loader builds a cyclic object and serialisation dies with TypeError: Converting circular structure to JSON in JavaScript or ValueError: Circular reference detected in Python. Expanding anchors is also worth eyeballing in a JSON editor before you ship the result, because the shape often is not what the author intended.

A YAML stream can hold several documents separated by ---, which is how a Kubernetes Deployment and its Service travel in one file. JSON holds exactly one value, so a converter must pick: take the first document, wrap them in an array, or refuse. js-yaml refuses, with expected a single document in the stream, but found more — use loadAll, or safe_load_all in Python, when you need all of them.

Mapping keys in YAML can be any node, and JSON keys are strings. 1: a and true: b convert to the keys "1" and "true", which means an integer key and a string key that look alike will collide into one entry; sequence keys have no representation at all. Explicit tags are the last category: !!binary produces bytes that will not serialise, and application tags such as CloudFormation's !Ref stop the load outright — PyYAML with could not determine a constructor for the tag, js-yaml with unknown tag. Those files need the vendor toolchain, not a generic converter. Comments, of course, are gone in every case, which is the real argument for keeping the YAML as the source of truth and treating the JSON as a build artefact.