YAML to JSON converter

How the conversion works

The page loads js-yaml — the parser most Node tooling already depends on — from this site rather than a CDN, and calls it on your text about a sixth of a second after you stop typing. That delay keeps a large manifest from being re-parsed on every keystroke while still feeling immediate. The parsed value is printed with the browser's own JSON.stringify at the indentation you chose.

Most of the work is in what YAML calls scalar resolution: deciding whether an unquoted 1.0 is a number, whether true is a boolean, and whether 2024-01-05 is a date. js-yaml follows the YAML 1.2 core schema, in which only true and false are booleans. yes, no, on and off stay strings. That is worth knowing if the file came from a YAML 1.1 parser such as PyYAML, which reads all six as booleans — the JSON you get here may legitimately differ from what your Python script sees.

JSON is a subset of YAML in practice, so anything already written as JSON passes through unchanged apart from formatting. The reverse is not true, which is why a few YAML features have to be flattened on the way out: comments are dropped, because JSON has nowhere to put them, and non-string mapping keys are stringified.

Questions people ask

What happens to dates and timestamps in my YAML?

An unquoted timestamp is resolved by the parser into a JavaScript Date. JSON has no date type, so it is then printed as an ISO 8601 string in UTC: 2024-01-05 comes out as "2024-01-05T00:00:00.000Z". A local time with an offset is converted to UTC on the way, which shifts the hour you see. If you want the original characters back, quote the value in the YAML — "2024-01-05" with quotes stays exactly those ten characters, because a quoted scalar is always a string.

My file has several documents separated by three hyphens. What comes out?

A JSON array, one entry per document, in the order they appeared, and the status line tells you how many were found. Kubernetes manifests and Helm output are almost always multi-document, and JSON has no equivalent of the separator, so an array is the only lossless answer. A single leading separator at the top of a file is not a split, so a file that opens with one still converts to a plain object. Two separators with nothing between them produce a null entry rather than being silently dropped.

The error points at a line that looks fine. Why?

YAML errors are reported where the parser runs out of options, which is often a line or two after the line that actually needs fixing. Indentation is the usual cause: a mapping entry indented one space too far reads as a continuation of the previous value until something makes that impossible. Look at the line above the reported one, and check that every key at the same level of nesting starts in the same column. The numbers shown here are already converted to the one-based line and column your editor uses; the library counts from zero internally.

Are anchors and aliases resolved?

Yes, and they vanish in the process. An anchor marks a value, an alias reuses it, and a merge key folds one mapping into another. All of that is expanded before anything is printed, so the JSON holds a full copy at every place the alias appeared rather than a reference — which is the only thing JSON can express. An alias with no matching anchor is an error and is reported as one. Recursive structures cannot be represented in JSON at all and will fail rather than hang.

Why does a tab character break my YAML?

Because the specification forbids tabs for indentation. Tab width is not defined anywhere, so a file indented with tabs would nest differently depending on who opened it, and the parser refuses rather than guess. Editors configured to expand tabs to spaces hide the problem entirely; ones that are not will produce a file that fails here with a message about the character. Tabs inside a quoted string are perfectly legal. If a file you did not write fails for no visible reason, switch on whitespace display and look at the indentation.