YAML Validator
Check YAML-like lines for indentation, keys, duplicates, and quotes. This is not a full YAML 1.2 parser.
🔒 Processed entirely in your browser — nothing you enter here is ever uploaded.
The result appears on this page after you run the tool. Nothing you enter is uploaded.
Result
About this tool
The checker walks lines. It is not js-yaml and it does not implement YAML 1.2. A blank line or a line whose trimmed text starts with # is skipped. Indentation must be spaces. A tab in the leading whitespace fails with YAML does not allow tab characters for indentation. The indent stack starts at 0. A deeper indent pushes a new level. A shallower indent pops until it matches a level already on the stack. An indent that matches none of those levels fails as inconsistent indentation, and the message includes the space count it found and the count it expected.
A trimmed line that starts with a dash is a list item. An empty item is accepted. If the rest contains a colon, the key before that colon must match the letters, digits, underscore, hyphen, and slash pattern, or the line fails as an invalid key name in a list. A line that is not a list item must contain a colon. The key is the text before the first colon. An empty key fails. The key must match a second pattern that also allows dots, spaces, quotes, and an optional [index]. The same key text, with surrounding quotes removed, cannot appear twice at that indent. The second one fails as a duplicate key. A value of | or > marks a literal or folded block: following non-empty lines that are indented deeper are skipped, and the block ends when a line returns to that indent or less.
Quotes are checked only in a simple way. A value that starts with a double quote and does not end with one, and is longer than one character, fails as unclosed double quotes. The same rule exists for single quotes. A value that is a single quote character is short enough to skip that test. Anything else after the colon is accepted, including numbers, the words true and false, and plain text. Flow syntax is not understood. A line such as {a: 1} has no top-level colon in the way the scanner wants a mapping line to have one only if the colon is present, and a brace-only structure is easy to reject as an invalid row. Anchors, aliases, tags, and multiline quoted strings that really span lines are outside the scanner. A document can receive YAML syntax is valid! and still be rejected by a real parser. On failure the box shows STATUS: INVALID, the line, and the message, and the page reprints two lines of context on either side. On success the message is YAML syntax is valid! The text is not uploaded. This pass does not mean a Kubernetes manifest or a GitHub workflow is semantically valid. Those files need their own schema. Use this page to catch a tab, a broken indent, a duplicate key, or a quote that never closes before you hand the file to a real parser.
Example. The line key: value is accepted. A second key: other at the same indent fails with Duplicate key detected. A leading tab fails with YAML does not allow tab characters for indentation.
Limit. This is a line scanner, not a YAML 1.2 parser. Anchors, aliases, tags, and flow collections are not implemented. A pass does not mean a Kubernetes or CI schema is satisfied.
Does a green result mean the YAML is really valid?
It means this scanner accepted the lines. The scanner checks spaces, indent levels, a colon or a dash, a small key pattern, duplicate keys at one indent, and a simple quote pair. It does not implement anchors, tags, or flow maps. A real YAML parser can still reject the same text.
Why are tabs rejected?
If the leading whitespace contains a tab, the line fails immediately: YAML does not allow tab characters for indentation. Use spaces. An indent that is not equal to a level already opened also fails, and the message names both space counts.
How are lists and multiline blocks treated?
A line that starts with - is a list item. If it also contains a colon, the key has to match a limited pattern. A value that is exactly | or > starts a block, and deeper lines are skipped until the indent comes back. Those markers are not fully parsed as YAML block scalars.
Will it validate a Kubernetes manifest?
Only as generic lines. apiVersion and kind are ordinary keys. Required fields, api groups, and controller rules are not checked. Duplicate keys at the same indent are reported. Schema checks belong to a manifest linter.