YAML Validator
Check YAML 1.2 syntax with precise error positions, and catch the duplicate keys that other parsers swallow in silence.
YAML to check
Validation result
A CI pipeline that refuses to start, a kubectl apply that fails with a message about mapping values, a Compose file that ignores half of what you wrote — YAML failures are rarely dramatic and almost always caused by one wrong space. This validator parses your document as YAML 1.2 and reports the first fault with its exact line and column, so you can stop counting indentation by eye.
It also catches something several popular parsers will not tell you about: duplicate keys. PyYAML, Ruby's Psych and a number of config loaders accept a repeated key without a murmur and keep only the last value — which is how a badly resolved merge conflict, or a second services: block appended to a Compose file, quietly deletes half your configuration while every tool in the chain reports success. Here it is reported as an error, with the line and column of the offending second occurrence.
How to use the yaml validator
- 1
Paste or upload the YAML
A single document or a
----separated stream. Everything runs locally in a Web Worker, so nothing is transmitted. - 2
Read the result and any warnings
A valid document reports Valid YAML 1.2, how many documents the stream contains, and any warnings the parser raised — deprecated tags, unusual constructs. An invalid one reports the fault with its line and column.
- 3
Fix in place and re-check
Edit directly in the input pane and validate again. The normalised, formatted version of the document is shown alongside the verdict, which is often the fastest way to see that a block is nested one level deeper than you intended.
The errors that account for most failures
- Tabs used for indentation. Illegal in YAML, full stop. This is the number one cause of "my file looks fine but nothing parses", because a tab and a run of spaces are indistinguishable on screen.
- Inconsistent indentation. Sibling keys must line up in the same column. One extra space turns a sibling into a child, or produces a hard error, depending on where it lands.
- A missing space after the colon.
key:valueis a single scalar string;key: valueis a mapping. YAML requires the space and this trips up everyone coming from JSON. - Unquoted strings containing a colon-space.
message: error: not foundis ambiguous and rejected. Quote the value. - Unquoted strings starting with a special character. A value beginning with
*,&,@,%,{,[,!or|means something structural to the parser. Quote it. - Wrong list indentation under a key. Both forms are legal — the
-may sit at the parent key's column or be indented under it — but mixing the two within one block is not.
Duplicate keys, and why implementations disagree
The YAML specification says the keys of a mapping must be unique, but implementations enforce that with wildly varying enthusiasm. PyYAML and Ruby's Psych accept duplicates silently and keep the last occurrence. Several Kubernetes and Go toolchains have changed their behaviour between versions. The parser behind this validator enforces the rule: a repeated key is reported as an error, naming the line and column of the second occurrence.
That strictness is the point. The realistic ways duplicates appear are mundane and common — a merge conflict resolved by keeping both sides, a generated block concatenated onto a hand-written file, a second env: or services: section added by someone who did not scroll up, a template that emits the same key twice. In every case the file's effective contents differ from what a human reading it top to bottom would conclude, and a duplicated top-level key can drop an entire section without a single error message anywhere in your pipeline.
The practical consequence of the disagreement between parsers is worse than either behaviour on its own: a file with duplicate keys can work in your local tooling and fail in CI, or the reverse. Finding them before the file ships is the cheap option.
Syntax validation, not schema validation
This tool answers whether your document is well-formed YAML. It does not check it against a schema — it does not know that a Kubernetes Deployment requires spec.selector, or that a GitHub Actions workflow needs a jobs key, or that replicas must be an integer.
A file can therefore be perfectly valid YAML and still be rejected by the system consuming it. For that layer, use the tool that owns the schema: kubectl apply --dry-run=server, docker compose config, or your CI provider's own linter. Syntax validation is the fast first pass that eliminates the majority of failures in a couple of seconds; schema validation is the second pass.
YAML Validator FAQ
Why is my file valid here but rejected by Kubernetes or GitHub Actions?
Because those systems apply a schema on top of the syntax. Valid YAML with a misspelled field name, a missing required key or a string where an integer belongs will parse cleanly and still be rejected. Use kubectl apply --dry-run=server or your CI linter for that layer.
Why does <code>ENABLE_CACHE: yes</code> come out as a string?
Because this parser follows YAML 1.2, where only true and false are booleans. Under the older YAML 1.1 rules, yes, no, on and off were booleans too — the source of the "Norway problem", where the country code NO became false. Quote such values explicitly and every parser agrees.
Are duplicate keys reported?
Yes, as an error, with the line and column of the repeated key. The specification requires mapping keys to be unique, but PyYAML, Psych and several config loaders accept duplicates silently and keep the last value — so a file that passes elsewhere can legitimately fail here. That is the tool doing its job: the earlier value was being discarded without telling you.
Does it validate multi-document streams?
Yes. Documents separated by --- are each parsed and checked, and the result reports how many the stream contains. A syntax error in any one of them fails the whole check, with the line number relative to the full input.
Is my YAML uploaded anywhere?
No. Parsing runs in a Web Worker in your browser and there is no server-side component. That matters for YAML in particular, since manifests and CI configs routinely carry hostnames, service accounts and occasionally a secret that should not have been committed.