YAML Validator
Max 1 MB · Validates automatically as you type · Multiple ----separated documents are all checked
- Documents
- Type
- Top-level keys
- Max depth
- Total nodes
Processed entirely in your browser — nothing is sent to a server.
Validating YAML means checking that a document is syntactically well-formed — correctly indented, no stray tab characters, no duplicate keys in the same mapping, every quote and bracket matched — the same check any YAML-consuming program has to pass before it can do anything with the file at all. This is a narrower guarantee than schema validation, which additionally checks that a document’s fields are the right ones for whatever it’s meant to represent (a Kubernetes Deployment needs specific keys in specific places; a GitHub Actions workflow expects a particular shape). A YAML file can be perfectly syntactically valid and still be rejected by kubectl apply or a CI runner because it’s missing a required field or has one in the wrong place — this tool catches the first kind of problem, not the second, and says so plainly rather than implying a broader guarantee than it actually gives.
Common syntax mistakes this tool catches directly: inconsistent or incorrect indentation (YAML’s structure is defined entirely by indentation, so a line indented one space off from where it should be changes what the document means, or breaks it outright); tab characters in indentation (YAML’s spec requires spaces only — a single tab, often introduced by an editor’s auto-indent, is a hard syntax error, not a style nitpick); unquoted values that collide with YAML’s own special syntax (a value starting with *, &, !, or : without a following space, or one that looks like a number/boolean when a literal string was intended); and duplicate keys within the same mapping, which are rejected outright rather than silently resolved by keeping whichever one appeared last.
Why this matters in practice: YAML is the format underneath most infrastructure and CI/CD tooling — Kubernetes manifests, Docker Compose files, GitHub Actions and GitLab CI pipeline configs, and Ansible playbooks are all YAML, and a syntax error in any of them typically surfaces as an unhelpful runner error well after the fact, not at edit time. Catching the mistake locally, with an exact line and column, is faster than a failed deploy or a broken pipeline run. This tool also checks every document in a ----separated multi-document file, not just the first — a gap in many other online YAML validators, and a real risk for exactly the multi-resource Kubernetes manifests and multi-play Ansible files this tool is built for.
Examples
- Debugging a failing CI/CD pipeline — paste a GitHub Actions workflow or GitLab CI config that's failing with an unhelpful runner error, and get the actual line and column where the YAML itself breaks, before ever pushing a fix and waiting on the pipeline again.
- Checking a Kubernetes manifest before applying it — validate a multi-document manifest (a Deployment and a Service in one file, separated by <code>---</code>) to catch a stray tab or a bad indent locally, rather than waiting on <code>kubectl apply</code> to reject it. For converting that same manifest to or from JSON, see JSON to YAML Converter.
- Reviewing an Ansible playbook or Docker Compose file — paste a playbook or <code>docker-compose.yml</code> pasted from a teammate or an old backup to confirm it's still syntactically sound before running it, especially after a hand edit where a misplaced space is easy to introduce and hard to spot by eye.
Frequently asked questions
Is my YAML sent anywhere?
Does this validate against a schema, like a specific Kubernetes resource type?
Why does my YAML fail with a tab-related error?
What happens with duplicate keys in the same mapping?
duplicated mapping key), not silently resolved by keeping the last one — a mapping is only well-formed with unique keys, and a document that violates that is exactly the kind of subtly-wrong config that's worth catching before it reaches whatever actually reads it, where a duplicate key might get silently overwritten with no warning at all.Does this handle a file with multiple YAML documents, separated by ---?
--- separator and never look at what comes after. Each document is validated independently; if one fails, the error names exactly which document (by position) and where in it the problem is, and every document before it is still confirmed valid rather than the whole file being reported as one undifferentiated failure.