YAML Validator

What this tool does

This tool parses YAML and reports whether it's syntactically valid. If it isn't, it shows the exact line and column of the first problem along with the parser's own explanation, instead of a generic "invalid" message. Validation uses a standard YAML 1.2 parser, so a document that passes here is well-formed YAML. Some tools still parse YAML 1.1 or add their own rules on top, so a passing document can in rare cases be read differently (for example, yes is a string in 1.2 but a boolean in 1.1).

When you need it

• Debugging why a GitHub Actions workflow, Kubernetes manifest or Docker Compose file fails to load, when the error message from the platform itself is unhelpful or buried in a stack trace.
• Checking a config file before committing it, especially after hand-editing YAML that was originally generated by a tool.
• Verifying a YAML snippet pasted from documentation or a chat message actually parses before dropping it into a real config.
• Teaching or learning YAML syntax, where seeing exactly which line broke and why is far more useful than a pass/fail result.

Why tabs are the most common failure

YAML's indentation-based structure forbids tab characters entirely — the specification requires spaces, because tab width isn't standardized across editors and terminals, and allowing tabs would make the same file parse into different structures depending on the viewer. Many code editors insert a tab character when you press the Tab key unless explicitly configured otherwise, which makes this the single most common way an otherwise well-formed-looking YAML file turns out to be invalid. This tool flags the exact line the first tab appears on, since a file with a tab early on can otherwise be confusing to debug — later lines may look identically indented in your editor while parsing completely differently.

Duplicate keys

YAML mappings require every key to be unique. Repeating a key — often from copy-pasting a block and forgetting to rename or remove the duplicate — doesn't raise an obvious warning in most editors, since the file still looks reasonable at a glance. This validator catches it explicitly, at the exact line where the repeat occurs, rather than silently keeping only the last value the way a lenient parser might.

Multiple documents and aliases

A file with several ----separated documents, as used in Kubernetes manifests, is valid and is checked document by document; the first error across all of them is reported. An alias that points at an anchor that was never defined (b: *missing) is also reported, with its line and column, even though the YAML text is otherwise well-formed.

What this doesn't check

This tool validates YAML syntax only — it confirms the document parses into a well-formed structure. It does not check that structure against a schema, so a syntactically valid document that's missing a field your application expects, or has a value of the wrong type, won't be flagged here. For structural validation against defined rules, use a JSON Schema validator on the parsed data, or your platform's own schema-aware linter (for example, a Kubernetes-specific validator understands what fields a Deployment manifest requires; this tool only confirms the YAML itself is well-formed).

Limits

Input is capped at 2 MB of YAML text, well beyond the size of any typical config file. Only the first error is reported, since YAML parsers — like most parsers — stop at the first structural problem; later content can't be reliably checked until everything before it is known to be valid.