YAML Linter & Validator

A YAML linter is a tool that checks your YAML files for both syntax errors (things that will crash your parser) and style/best-practice warnings (things that may cause subtle bugs or confusion). Unlike a simple validator that only tells you if the file is parseable, a linter also flags risky patterns like unquoted boolean keys, deeply nested structures, and ambiguous values like 'yes' or 'no' that different YAML parsers may interpret differently.

In YAML 1.1 (used by many tools including PyYAML and older Ruby parsers), the values 'yes', 'no', 'on', and 'off' are treated as boolean true/false. In YAML 1.2 (the current spec), only 'true' and 'false' are booleans. This means a config file that works with one tool may silently break with another. The safe practice is to always quote these values: '"yes"' or '"no"' when you intend them as strings.

In YAML, mapping keys are parsed the same as values. A key written as 'yes:' or 'true:' is technically a boolean key, not a string key. Most parsers will coerce it back to the string 'true', but behavior is inconsistent across implementations. Writing '"yes": value' or '"true": value' ensures the key is always treated as a string regardless of the YAML spec version being used.

The YAML specification explicitly forbids tab characters for indentation. Tabs cause ambiguity because different editors and systems may display or expand them differently (4 spaces? 8 spaces?). The spec mandates spaces so that indentation levels are unambiguous. If your editor inserts tabs, configure it to use spaces (or 'expand tabs') for YAML files.

When your YAML mapping nests more than 5 levels deep (e.g., config.server.tls.certs.ca.path), it becomes hard to read and maintain, and is also a common sign that the data model should be restructured. Fixes include: splitting into separate YAML files and referencing them, using YAML anchors (&anchor) and aliases (*alias) to share repeated sub-trees, or flattening the structure with dotted keys.

The Format button normalizes your YAML indentation to a consistent 2-space style. It detects your current indentation unit (e.g., 4-space or mixed), computes nesting levels, and rewrites each line's leading whitespace to multiples of 2 spaces. The YAML content itself is not changed — only the leading whitespace is normalized. Blank lines and comments are preserved as-is.