YAML Validator
Validate YAML with a strict YAML 1.2 parser, get document-level syntax diagnostics, and separate real parser failures from schema or application-specific configuration rules.
Multi-document streams are supported. Duplicate mapping keys are treated as parser errors.
0 lines
Validation result
Strict YAML 1.2 syntax/composition is checked here; application schemas are not.
YAML parser summary will appear here.
When YAML Breaks, the Error Is Often One Character Away From the Real Cause
YAML uses indentation and punctuation to express structure, so a parser error reported on line 12 may have been caused by a missing quote, colon, closing bracket, or indentation change on line 11. Parser diagnostics include the line and column where composition failed instead of guessing from quote counts or indentation heuristics alone.
Read the highlighted location as the point where parsing could no longer continue confidently—not always as the exact character you should edit.
Indentation changes structure
Sibling mapping keys need the same indentation level. A single extra or missing space can move a value into another mapping or make the stream invalid.
Tabs are not indentation
YAML indentation uses spaces. A tab may appear inside some scalar content, but using tabs to create indentation is a parser error.
: and # are context-sensitive
A colon followed by separation can introduce a mapping value, and # can start a comment in plain-scalar contexts. Quote text when punctuation would otherwise be interpreted as YAML structure.
Flow collections still follow YAML rules
Bracketed sequences and brace-style mappings look JSON-like but are still parsed as YAML and have their own indicator and separation rules.
Duplicate Mapping Keys Are Not a Harmless “Last One Wins” Style
YAML mappings require unique keys. Silently keeping the last value can hide configuration mistakes—especially when a long deployment file contains two copies of image, environment, or another important setting. This strict parsing keeps unique-key checking enabled and reports duplicates as errors. YAML 1.2 defines a mapping as a set of key/value pairs whose keys are unique.
Valid YAML Is Not the Same Thing as a Valid Kubernetes, Compose, or CI File
A parser can confirm that your stream obeys YAML syntax and composition rules. It cannot know that a Kubernetes Deployment has the required fields, a Docker Compose service references a real volume, or a CI workflow uses supported action keys.
Syntax validation answers “does this parse as YAML?” A second, product-specific pass is still needed for questions such as “does this Kubernetes resource satisfy its API schema?” or “does this Compose service reference something that actually exists?”
YAML Version and Schema Affect What an Unquoted Word Means
Syntax and scalar resolution are related but different. YAML 1.2 core treats familiar words such as yes, no, on, and off as strings, while YAML 1.1-oriented software has historically treated some of them as booleans. Application-specific schemas can add their own tags and conversions.
Documents without a version directive use YAML 1.2 as the default; an explicit %YAML 1.1 directive is reported separately. The YAML 1.2.2 specification defines the core schema in which true and false are booleans while words such as yes and on remain strings. A clean parse still does not promise that another application's YAML library uses the same version, schema, or custom tags.
Anchors and Aliases Are Valid YAML, but They Add a Graph Layer
Anchors such as &defaults name a node and aliases such as *defaults refer back to it. They can reduce repetition, but downstream applications differ in whether they accept aliases, impose expansion limits, or transform them into ordinary values.
Their presence is reported as a review note rather than an error. For untrusted YAML, the consuming parser should also have sensible alias and resource limits so deliberately expansive graphs cannot exhaust memory or processing time.
Multi-Document Streams Are Normal YAML
A stream can contain several YAML documents, commonly separated by ---. Kubernetes files often use this to keep several resources together. A validator that assumes one document can wrongly reject perfectly valid YAML or inspect only the first resource.
The complete stream is parsed and each document's root type and effective YAML version are reported, making it clear whether the input contains one mapping, several documents, a sequence, a scalar, or an empty document.
Validate Rendered YAML, Not Only the Template Source
Helm, Jinja-style templates, CI substitutions, and other generators may contain {{ ... }} or other syntax that is not the final YAML sent to the application. The template can be internally correct while the rendered output is broken for one set of values—or the template source can fail a generic YAML parser even though rendering would remove the placeholders.
For deployment confidence, render with representative production values and validate the resulting YAML as a separate step.