Validate YAML

How to use it#

1. Drop a .yaml or .yml file on the box, or paste the YAML into it.
2. Read the verdict. An error names the problem and shows the line with a caret under the column.
3. On a valid file, read any warnings: values that parse here but that other YAML parsers read differently.

Reading the error#

Most YAML errors are indentation. Spaces are the structure, so a key one space further in than its neighbours belongs to a different parent, and the parser reports bad indentation of a mapping entry. A tab used for indentation is refused outright, since YAML does not allow tabs there at all. The caret under the line shows the column where the parser gave up.

That column is where the problem became impossible to ignore, which is not always where it started. An unclosed quote or bracket is usually reported further down, at the point the parser ran out of ways to read on, so if the marked line looks fine, check the lines above it.

A duplicated key is an error here as well. Some parsers keep the last value without a word, which is how a setting that was overridden by accident goes unnoticed for months.

Why a valid file can still be wrong#

YAML guesses types from bare values, and the guesses changed between versions. This page follows YAML 1.2, where yes, no, on, and off are plain text. PyYAML and many older tools follow YAML 1.1, where all four are booleans. A country list with NO for Norway parses fine here and turns into false elsewhere, which is why this is known as the Norway problem. The warnings list every bare value the two versions read differently, with its line, so you can quote the ones that matter.

Numbers get the same treatment. A version written 1.20 is the number 1.2 to every parser, a file mode like 0755 is 755 here and 493 under YAML 1.1, and an ID longer than about sixteen digits cannot be held exactly as a number. Each is valid YAML, and each is flagged, because quoting it is almost always what was meant. So are a time written 1:30, which YAML 1.1 reads as the number 90, and a bare date such as 2024-03-01, which it turns into a date object while YAML 1.2 keeps it as text.

Keys are left out of the warnings on purpose. The on: at the top of a CI workflow is read as a boolean by YAML 1.1 parsers, but the systems that read those files handle it, and flagging it on every workflow would bury the warnings that matter.

Validating, then converting#

A file that passes here parses the same way in the YAML to JSON converter, which shows exactly what each value became: a string in quotes, a bare number, or true. That is the quickest way to settle an argument about what a value means. Both pages understand merge keys, the <<: *defaults that Compose files and CI configs use to share settings, and both refuse one that points at something other than a mapping.

Going the other way, the JSON to YAML converter writes YAML from JSON with anything ambiguous already quoted.