YAML Validator

What this checks

• Syntax errors — bad indentation, unclosed flow collections ([...]/{...}), invalid escapes, and similar, with the line and column where parsing failed.
• Duplicate keys. The same key appearing twice in one mapping is legal in some lenient parsers but rejected here — it's almost always a mistake, and which value "wins" is inconsistent across tools.
• Tabs used for indentation. The YAML spec forbids it outright — only spaces are valid for structural indentation.
• Unresolved aliases and custom tags — a *name reference with no matching &name anchor, or a !!tag this parser doesn't recognize.
• YAML 1.1/1.2 boolean ambiguity (informational). An unquoted yes, no, on, off, or a country code like NO is plain text under YAML 1.2 (what this tool and most modern parsers use) but becomes a boolean under YAML 1.1 — the infamous "Norway problem." Flagged so you can quote it deliberately if a stricter or older parser might read your file too.

Multi-document files (separated by a line containing just ---) are validated document by document, with results numbered accordingly. Merge keys (<<: *anchor) are resolved — a widely-supported extension, though not part of core YAML 1.2 itself.

FAQ

Does this validate against a specific schema (like Kubernetes or Docker Compose)?

No — this checks that the YAML itself is well-formed, not whether it satisfies some application's expected structure. For Kubernetes manifests specifically, see Kubernetes YAML Validator, which checks apiVersion/kind correctness, resource naming rules, and more on top of syntax.

Why does my file parse fine here but fail elsewhere?

Most likely the YAML 1.1 boolean issue above, or a parser-specific extension (custom tags, a non-standard merge key implementation) that this tool — deliberately following the common YAML 1.2 core schema — doesn't special-case the same way.

Try it yourself

For Kubernetes-specific validation, formatting, and diffing, see the Kubernetes Toolkit.