YAML lint
YAML Validator
Find out what is wrong with your YAML — and where.
Paste your YAML here, or drop a file anywhere on the page
JSON appears here as you type
Free and unlimited · No sign-up · Every error carries the exact line and column, a plain-English explanation, and a suggested fix.
What gets checked
Syntax
Indentation, tabs, unclosed brackets and quotes, and malformed mappings and sequences.
Structure
Duplicate keys, which YAML rejects and which would silently collapse in JSON.
References
Aliases pointing at anchors that don’t exist, and anchors declared without a name.
Safety
Runaway alias expansion — the “billion laughs” shape — before it can hang the page.
Portability
Values that change meaning between YAML 1.1 and YAML 1.2, flagged with what each version produces.
Tags
Custom tags such as !Ref or !GetAtt that have no standard meaning outside their own tooling.
Valid YAML isn’t always correct YAML
A document can parse perfectly and still mean something you didn’t intend. The classic case is country: no, which is valid under both YAML versions but produces the string "no" in one and the boolean false in the other.
That’s why this validator reports two different things. Errors mean the document can’t be parsed at all. Warnings mean it parses, but a value would be read differently by another tool — worth knowing before a Kubernetes manifest reaches a cluster.
If you want to understand the error before fixing it, the guide Common YAML errors and how to fix them walks through the six mistakes behind almost every failed parse — tabs, unquoted colons, unclosed brackets, duplicate keys, missing anchors, and uneven indentation — with a before-and-after for each.
Frequently asked questions
What does this YAML validator check?
Syntax first: indentation, tabs, unclosed brackets and quotes, and malformed mappings and sequences. Then structure: duplicate keys, aliases that point at anchors that were never declared, and runaway alias expansion. Then portability: custom tags such as !Ref that have no meaning outside their own tooling, and every unquoted value that YAML 1.1 and YAML 1.2 read differently. Each problem comes with the line and column, a plain-English explanation, a suggested fix and a marker in the editor.
Why does my YAML validate but still behave wrongly?
Because valid is not the same as correct. country: no parses cleanly under both YAML versions, but it is the string "no" in YAML 1.2 and the boolean false in YAML 1.1, which is how a country disappears from a list without any error. The same applies to 022, 12:30 and 1e3. This validator reports those as warnings rather than errors: the document parses, but another tool would read a value differently. Quote the value to make it unambiguous.
What does “mapping values are not allowed in this context” mean?
The parser found a colon followed by a space in a place where a value was already being read. The usual cause is an unquoted value that itself contains a colon, such as title: Deploy: production or a URL written without quotes. Wrap the value in quotes. The other cause is a key indented differently from the keys around it, so the parser reads it as part of the previous value.
What does “found character that cannot start any token” mean?
Almost always a tab character used for indentation, which YAML forbids. Editors that convert tabs to spaces hide the problem until a file is edited elsewhere. Replace the tab with spaces and keep every sibling at the same width; the validator points at the exact line. The same message appears for a stray control character or an @ or backtick at the start of a value.
What does “did not find expected key” mean?
The parser was reading a mapping and expected the next line to be another key at the same indentation, but found something else. Look at the line before the one reported: a value with one more space of indentation than its siblings, a dash that starts a list where a key was expected, or a value that should have been quoted. The validator recovers the real cause for unclosed brackets and quotes, which most parsers misreport under this message.
Does it validate against a schema, such as Kubernetes or OpenAPI?
No. It checks that the document is well-formed YAML and that it means the same thing to every parser; it does not know which keys a Deployment or an OpenAPI document may contain. For Kubernetes, kubectl apply --dry-run=client -f file.yaml checks a manifest against the cluster’s schema. For OpenAPI, GitHub Actions or JSON Schema, run the file through the schema validator for that format after it passes here.
Is my YAML uploaded when I validate it?
No. Validation runs in your browser; there is no server endpoint to send the document to, and the page keeps working after you disconnect. Configuration files are exactly the kind of thing that carries hostnames, internal paths and the occasional secret, which is why the tool was built this way.
How do I validate YAML from the command line?
yamllint file.yaml reports syntax errors and style problems and is the usual choice in CI. yq . file.yaml prints the document or fails with a parse error. In Python, python -c "import sys, yaml; yaml.safe_load(sys.stdin)" < file.yaml fails on invalid YAML, though PyYAML reads YAML 1.1, so it will also treat no as false. None of these explain the error the way the validator above does; use them to fail a pipeline, and this page to find out why.
Parser messages, explained
If you arrived with an exact error string, each of these has its own page with every cause, the fix, and how to read the line number.