YAML Validation
The whitespace-sensitive format behind Docker, Kubernetes, and CI pipelines
YAML ("YAML Ain't Markup Language") is the format behind most of modern infrastructure-as-config: Docker Compose files, Kubernetes manifests, GitHub Actions and GitLab CI pipelines, and countless application config files. Its appeal is that it reads almost like plain English — no braces, no quotes required for simple strings — but that same minimalism is exactly what makes it fragile to hand-edit. YAML's structure is defined entirely by indentation and whitespace, and unlike most programming languages, the YAML spec forbids tab characters for indentation entirely — a file that looks perfectly formatted in an editor that renders tabs as spaces can fail to parse because of an invisible tab character mixed into space-indented lines.
Beyond tabs-vs-spaces, YAML's other common failure modes are subtle: inconsistent indentation between sibling keys, duplicate keys (which YAML silently allows by default, with the last one winning rather than raising an error), unclosed quotes, and the distinction between YAML's "block style" (indentation-based, most common) and "flow style" (JSON-like braces and brackets, valid inline within a YAML document). A misconfigured Kubernetes manifest or CI workflow often fails not because the logic is wrong, but because of one of these small, easy-to-miss syntax issues.
Yamlite validates YAML the moment you paste it, entirely offline, and reports errors down to the exact line and column — the difference between staring at a wall of config and knowing precisely which line broke the parse.
The app
Frequently asked questions
Why does YAML forbid tab characters for indentation?
The YAML specification explicitly disallows tabs for indentation because tab width isn't standardized — the same tab character can render as 2, 4, or 8 spaces depending on the editor or terminal, which would make indentation-based structure ambiguous. A file that visually looks correctly indented can still fail to parse if a tab snuck into what should be space-only indentation, which is one of the most common and hardest-to-spot YAML errors.
What's the difference between YAML and JSON?
YAML is a superset of JSON in the sense that valid JSON is (with minor exceptions) also valid YAML in flow style. YAML additionally supports block style (indentation-based, no braces), comments (which JSON doesn't allow at all), multi-line strings, and references/anchors for reusing values within a document. YAML is generally preferred for human-edited config files because it's less visually noisy; JSON is generally preferred for machine-to-machine data interchange where strictness matters more than readability.
Why does YAML allow duplicate keys without an error?
The YAML 1.1/1.2 spec doesn't require parsers to reject duplicate keys within the same mapping — most parsers simply let the last occurrence silently override earlier ones. This is a common source of bugs in larger config files where a key gets accidentally redefined further down, and it's part of why a strict validator that flags duplicates explicitly (rather than just silently accepting the file) is useful beyond basic syntax checking.
What's the difference between YAML's block style and flow style?
Block style is YAML's default, indentation-based layout — no braces or brackets, structure defined purely by whitespace. Flow style uses JSON-like inline syntax with `{}` for mappings and `[]` for sequences, and can be mixed into an otherwise block-style document for compact inline values. Flow style is less common in hand-written config but shows up often enough that a validator needs to handle both.