YAML validator
Check whether your YAML is valid and pinpoint syntax errors. Runs in your browser.
Runs 100% in your browserHow to validate YAML
- Paste your YAML. Paste a config file, Docker Compose file or CI workflow into the editor.
- Read the result. A green check means it parsed; a red error gives the parser message and the line to look at.
- Fix and re-check. Correct the flagged line — usually a tab or an indentation slip — and it re-validates as you type.
What this validator checks — and what it doesn't
This tool answers one precise question: does your document parse as valid YAML? It runs the same parser your tools use, so a green check means the indentation, quoting and structure are all legal. What it deliberately does not do is check your document against a schema — it can't know that a Kubernetes manifest is missing a required field, because that's a different layer. Valid YAML and a correct config are two separate things, and this catches the first, faster than a failed pipeline run does.
The mistakes that actually break YAML
YAML's readability comes from significant whitespace, which is also where almost every error comes from:
- Tabs. A tab in an indentation position is illegal — YAML uses spaces only. This is the single most common cause and the hardest to spot, because a tab and spaces look identical.
- Inconsistent indentation. Sibling keys must line up at the same column; drift by one space and the structure changes or fails.
- Unquoted colons. A value like
time: 10:30confuses the parser — the inner colon-space looks like a new mapping. Quote it:"10:30". - Duplicate keys. Two keys with the same name in one mapping is invalid (or silently keeps the last one, depending on the parser).
Valid isn't always what you meant
The subtler trap is a file that parses cleanly but is read differently than you intended — unquoted
no becoming false, 1.10 losing its trailing zero. When a value must
stay a string, quote it. To see exactly how a document turns into data, paste it into the
YAML to JSON converter, and
use the JSON formatter to
inspect the parsed result.
Frequently asked questions
- It parses your document with a full YAML parser (js-yaml) and confirms it is well-formed — that the indentation, quoting and structure are all legal. If parsing fails, it shows the parser's error message and the line it choked on, so you can jump straight to the problem.
- By far the most common cause is a tab character used for indentation — YAML forbids tabs for indentation, only spaces. After that: inconsistent indent depth between sibling keys, a value containing an unquoted
:(colon-space) that the parser reads as a new key, and unclosed quotes or brackets. The error line points you at the spot. - No — this checks YAML syntax, not whether your fields match a particular spec. A document can be perfectly valid YAML while being a broken Kubernetes manifest. For field-level rules use a schema-aware linter (kubeval, actionlint, or an editor with the matching JSON Schema).
- Validity and correctness are different things. Depending on the parser that ultimately reads the file, unquoted scalars can be coerced in surprising ways: the famous "Norway problem" turns the country code
nointo the booleanfalse,version: 1.10becomes the number1.1(the zero is lost), and007becomes7. Quote any value you mean literally —"no","1.10"— to be safe across tools. - Spaces, always — YAML treats a tab in an indentation position as an error. Set your editor to insert spaces and to render whitespace so a stray tab is visible. Two spaces per level is the common convention.
- Yes — js-yaml is loaded into your browser and validation runs locally, so a config containing internal hostnames or secrets never leaves your device.