Gera Tools

YAML Linter

Lint YAML for syntax errors, duplicate keys, and common gotchas

Scans YAML for the mistakes that bite in practice: tab indentation, duplicate keys in a mapping, missing space after a colon, unbalanced flow brackets, and values like yes or 01.2 that get coerced. Runs in-browser, safe for secrets. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

What problems does the linter catch?

It catches tab characters used for indentation, duplicate keys in the same mapping, a missing space after a mapping colon, unbalanced flow brackets, trailing whitespace, and ambiguous unquoted values that YAML coerces.

YAML is whitespace-sensitive and quietly forgiving, which makes its failure modes especially nasty: a tab where a space belongs, two keys with the same name where only the last survives, or an unquoted yes that silently becomes a boolean. This YAML linter scans for those exact gotchas in your browser and explains each one.

How it works

The linter walks your file line by line, tracking quote state so that a # or colon inside a string is not mistaken for a comment or a mapping separator. For each line it checks several rules:

  • A tab character in the indentation is an error, because YAML forbids tabs for indentation.
  • Two keys at the same indent under the same parent are reported as a duplicate-key error; in real YAML only the last would win.
  • A mapping colon must be followed by a space or end of line, so key:value is flagged.
  • Flow collections must have balanced [ ] and { } on the line.
  • Trailing whitespace is reported as a warning.

Ambiguous values

YAML 1.1 coerces bare words like yes, no, on, and off into booleans, and a value such as 0755 can be read as octal. The linter warns on these so you can quote them when you mean the literal string or number. For example, in the sample, version: 01.2 and enabled: yes both raise warnings.

The mistakes that cause real outages

Most YAML errors fall into a small set of recurring categories. Understanding each helps you write safer configs the first time.

Tabs vs spaces. YAML’s specification forbids tab characters for indentation. Editors that mix them silently produce files that parse fine in one tool and fail in another, depending on whether the parser is forgiving. The correct fix is always to convert tabs to spaces — never to set a parser option to allow tabs.

Duplicate keys. YAML technically allows duplicate keys (the last one wins), but it is almost never intentional. A common way this happens: copy-pasting a block and forgetting to rename a key, leaving two name: entries in the same mapping. The first is silently dropped. The linter reports this as an error because it is always a bug.

The boolean trap. YAML 1.1 (which many parsers still implement) interprets bare yes, no, true, false, on, and off as booleans. This matters in configuration files where a field like ssl: no or debug: off is intended to be a string. The safe habit: quote any value that looks like it could be misread. YAML 1.2 narrows booleans to only true and false, but not all parsers have caught up.

Octal and leading zeros. A value of 0755 is parsed as octal 493 in YAML 1.1. This is intentional behaviour for file permission strings but an unpleasant surprise for version numbers or ZIP codes that happen to start with zero. Quote these values to preserve them literally.

Missing space after colon. key:value is valid YAML for a mapping key named key:value rather than a key-value pair. Most users intend the latter. The linter flags the missing space as an error.

Notes

This is a practical linter, not a complete YAML processor — it targets the mistakes that cause real outages rather than building a full document model. Use it as a fast first pass, then load the file through your own application’s parser to confirm the final structure. Everything runs locally, so configs containing secrets stay private.