YAML Validator

YAML (YAML Ain't Markup Language) is a human-readable data serialization format commonly used for configuration files, infrastructure-as-code (Kubernetes, Docker Compose, GitHub Actions), and data exchange. It represents data using indentation for structure, colons for key-value pairs, and dashes for list items. YAML is a superset of JSON — every valid JSON document is valid YAML, but YAML adds features like comments, multi-line strings, anchors, and aliases.

Key rules: (1) Use spaces for indentation — tabs are strictly forbidden and will cause a parse error. (2) Key-value pairs are written as "key: value" with a space after the colon. (3) Lists use a dash followed by a space: "- item". (4) Strings can be unquoted, single-quoted, or double-quoted. (5) Comments begin with # and extend to the end of the line. (6) Consistent indentation depth defines nesting — mixing indent levels within the same block is invalid. (7) Boolean values are: true/false, yes/no, on/off (case-insensitive).

The most frequent YAML mistakes are: (1) Tab characters instead of spaces — the most common cause of parse failures. (2) Inconsistent indentation — mixing 2-space and 4-space indents within a document. (3) Missing space after a colon — "key:value" is invalid; it must be "key: value". (4) Duplicate keys at the same level — later values silently overwrite earlier ones in many parsers. (5) Unclosed or mismatched quotes. (6) Colons inside unquoted string values — "url: http://example.com" will parse incorrectly without quotes around the value.

YAML is more human-friendly: it supports comments (JSON does not), requires less punctuation (no curly braces or commas needed), and allows multi-line strings naturally. JSON is stricter and more machine-friendly: it has a simpler spec, better tooling support, and unambiguous parsing. JSON is better for APIs and wire formats. YAML is better for config files humans read and edit regularly. YAML is a superset of JSON, so valid JSON is valid YAML, but YAML has more complex parsing rules which can lead to subtle bugs (e.g., "no" being parsed as boolean false in some parsers).

Recommended practices: (1) Use 2-space indentation consistently. (2) Always quote strings that contain special characters (:, #, {, }, [, ]), or that could be misinterpreted as another type (e.g., "true", "null", "1.0"). (3) Use double quotes for strings with escape sequences and single quotes for literal strings. (4) Avoid duplicate keys — validators will warn, but parsers often silently ignore them. (5) Keep documents short; split large configs into multiple files. (6) Use anchors (&) and aliases (*) to avoid repetition in large configs. (7) Validate YAML in CI/CD pipelines before deploying infrastructure changes.