Parsed structure (as JSON)
{
"apiVersion": "apps/v1",
"kind": "Deployment",
"metadata": {
"name": "nginx-deployment",
"labels": {
"app": "nginx"
}
},
"spec": {
"replicas": 3,
"selector": {
"matchLabels": {
"app": "nginx"
}
},
"template": {
"metadata": {
"labels": {
"app": "nginx"
}
},
"spec": {
"containers": [
{
"name": "nginx",
"image": "nginx:1.25",
"ports": [
{
"containerPort": 80
}
]
}
]
}
}
}
}js-yaml. Zero HTTP requests during validation — verify in DevTools' Network tab.About YAML Validator
A YAML validator parses YAML 1.2 source and reports syntax errors with line/column references. Distinct from schema validation: this checks SYNTACTIC validity (is the YAML well-formed?), not semantic correctness against a JSON Schema or domain-specific schema. Catches the typical YAML pitfalls: indentation errors (the #1 YAML bug), missing colons after keys, unquoted strings that look like booleans (`yes`/`no`/`on`/`off`), and duplicate keys in mappings.
Why use a YAML Validator?
YAML is whitespace-significant and visually deceptive — indentation must use spaces (not tabs); single-character spacing errors produce silent semantic shifts. CI/CD pipelines (Kubernetes manifests, GitHub Actions workflows, Docker Compose, Ansible playbooks) consume YAML and fail at runtime when invalid — validating locally first catches errors faster. The parsed-output preview confirms the document actually represents the structure you intended.
Who is it for?
DevOps engineers writing Kubernetes/Helm/Ansible YAML, CI/CD pipeline authors (GitHub Actions, GitLab CI, CircleCI), developers debugging YAML configuration in their applications, and anyone whose YAML 'looks right' but fails to parse in production.
How to use the tool
Paste your YAML content into the input area
The tool validates in real-time, showing syntax errors with line/column references
On success, the parsed structure is displayed as JSON for inspection (confirms structure matches intent)
Error messages indicate the YAML rule violated (indentation, missing colon, duplicate key, etc.)
Copy the parsed JSON output for use elsewhere, or fix the source and re-validate
Frequently Asked Questions
How do I validate YAML online?
Paste your YAML into the input area. The tool uses js-yaml (the de facto JavaScript YAML parser, used by Node.js tooling) to parse YAML 1.2 syntax. On error: line/column references + the specific issue (e.g., 'bad indentation of a mapping entry at line 5'). On success: the parsed structure is shown as JSON for inspection. Runs entirely in your browser — your YAML never leaves the device. Verifiable in DevTools' Network tab: zero HTTP requests during validation.
What's the difference between YAML syntax validation and schema validation?
Two separate concerns. **Syntax validation** (this tool): is the YAML well-formed? Catches indentation errors, missing colons, malformed strings, duplicate keys. The output is structurally valid YAML. **Schema validation**: does the YAML match a domain-specific structure? E.g., a Kubernetes manifest must have `apiVersion`, `kind`, `metadata.name`. YAML can be syntactically perfect but semantically wrong for its intended use. For schema validation, use tools like `kubeconform` (Kubernetes), `actionlint` (GitHub Actions), `ajv` with a JSON Schema, or domain-specific linters.
Is my YAML sent to a server?
No — validation runs entirely in your browser via js-yaml. Your YAML never reaches a server, never gets logged. Verify in DevTools' Network tab: zero HTTP requests during validation. Safe for sensitive configuration (Kubernetes Secrets, CI/CD pipeline configs with API tokens, internal Ansible playbooks). For maximum local privacy on large config repos, use `yamllint` or `js-yaml` CLI locally.
What are the most common YAML mistakes?
(1) **Indentation with tabs** — YAML forbids tabs for indentation; use spaces (most editors can show invisible characters). (2) **Inconsistent indent levels** — children must be indented MORE than parent; sibling keys must align. (3) **Missing space after colon** — `key:value` is invalid; needs `key: value`. (4) **Unquoted special strings** — `yes`, `no`, `on`, `off`, `true`, `false`, `null` become booleans/null; quote them as strings if literal. (5) **Duplicate keys** — silently overwrite earlier values (some parsers warn, js-yaml errors in strict mode). (6) **Tab vs space confusion** — visually identical but different bytes. Use an editor with show-invisibles.
What's the YAML 1.1 vs 1.2 difference?
**YAML 1.2** (2009) is the modern standard. Key changes from 1.1: (1) Removed the 'octal with leading zero' interpretation (`012` is now string '012', not 10). (2) Strict YAML/JSON compatibility — every YAML 1.2 document with flow style is valid JSON. (3) Removed Yes/No/On/Off as booleans (only `true`/`false`). Most modern parsers (including js-yaml) default to 1.2. Tools that still default to 1.1 (some Python `yaml` legacy modes, older Ruby `psych`) interpret some strings differently — a source of subtle bugs when YAML files move between ecosystems.
Why does my Kubernetes YAML fail despite valid syntax?
Syntax-valid YAML can still be semantically wrong for Kubernetes. Common cases: (1) Missing required fields (`apiVersion`, `kind`, `metadata.name`). (2) Wrong types (a port number as a string). (3) Indentation that's valid YAML but wrong K8s structure (the spec deeply-nests; one extra indent puts a field in the wrong section). (4) Multi-document YAML files without `---` separators between documents. For Kubernetes-specific validation, use `kubectl apply --dry-run=client -f file.yaml` or `kubeconform` (validates against K8s schemas without a cluster). This tool catches step 1 (is the YAML parseable?); K8s validation catches steps 2-4.
What about JSON inside YAML (flow style)?
YAML's flow style uses JSON-like syntax: `users: [{name: alice, age: 30}, {name: bob, age: 25}]`. Every JSON document is valid YAML — but the reverse isn't true (YAML's block style + advanced features aren't valid JSON). For interop, use [YAML to JSON](/tools/yaml-to-json/) to convert between formats. For storing structured data in CI/CD configs, YAML's block style is more readable; JSON's flow style is more compact but harder to edit. The choice is mostly stylistic — both produce the same parsed structure.
How do I find the exact line of an error?
js-yaml's parse errors include line/column references (e.g., `bad indentation of a mapping entry (5:3)` = line 5, column 3). The tool displays this. Common pitfalls: (1) The error's line might be where the parser DETECTED the problem, not where the BUG is — bad indentation 3 lines earlier can manifest as 'unexpected token' later. (2) YAML's whitespace sensitivity means the visible 'wrong' line might depend on the parser's heuristic. When stuck, comment out suspicious sections and bisect (parse half the file, then the other half). Use an editor with show-invisibles to spot tabs in indentation.
Share This Tool
Found this tool helpful? Share it with others who might benefit from it!
💡 Help others discover useful tools! Sharing helps us keep these tools free and accessible to everyone.