YAML Validator

Check YAML syntax and structure with line-and-column errors — duplicate keys reported instead of silently overwritten, unresolved aliases caught at the alias, multi-document streams accepted and counted. Syntax and structure only, stated plainly: not schema validation. Your input is never auto-saved: YAML is configuration, and configuration carries secrets. Free, no sign-up — runs locally in your browser.

Nothing here is auto-saved. YAML documents are usually configuration, and configuration files carry secrets — API keys, tokens, internal hostnames. This tool keeps no draft of your input, in your browser or anywhere else: paste, validate, done. Refresh the page and it is gone — that is deliberate.

Why a standalone validator, when the formatter exists?

Different question, different tool. The formatter answers “make this readable” — and refuses, along the way, anything it cannot parse. This validator answers the go/no-go question that comes before formatting in most pipelines: “is this document sound YAML at all?” A CI pipeline that rejects a deploy, a container that refuses to boot, a GitOps sync that silently stops applying — all of these are one YAML error wearing different clothes, and all of them are much cheaper to find here, with a line and column attached, than from a log file after the fact. The verdict also summarises the document — documents, mappings, sequences, scalar values, maximum nesting depth — so you can confirm you pasted the document you meant to check.

How to use this tool

  1. Paste the YAML, upload a .yaml file, or drop one onto the panel. With “Validate as I type” on, the verdict updates as you edit.
  2. Press Validate YAML. A ✓ verdict means the document parses as YAML: syntax sound, keys unique, every alias resolved.
  3. On a ✗ verdict, read the message: it gives the line and column of the offence. Fix, re-validate, repeat — parsers report one error at a time.
  4. Remember the scope line: this checks syntax and structure, not conformance to your application's schema. Valid YAML can still be the wrong configuration.

What it checks — and what it does not

Checked: indentation and block structure, flow syntax ([…] and {…}) properly closed, quoted strings properly terminated, duplicate keys in a mapping, aliases whose anchor is never set (or is set only later in the document), and tab characters in indentation, which YAML forbids. Multi-document streams are accepted and counted. Not checked: anything about meaning — required keys, value types, whether replicas: three should have been a number. That boundary is deliberate and matches what every YAML-consuming program enforces first: it cannot even begin on a document that fails here.

The errors people actually hit

The two-space drift — one line indented three spaces in a two-space file, so a key silently changes parent or the document stops parsing. The duplicated key — a block pasted twice after a merge; half the ecosystem would have taken one value, half the other. The unquoted colon — message: Error: not found is not a string, it is a syntax error. The tab — pasted from an editor that expanded differently. The dangling alias — *defaults whose &defaults block was edited away. Every one of these gets a precise verdict here, before your pipeline finds it the hard way.

Frequently asked questions

What exactly does this check — and what does it not check?

It checks YAML syntax and structure: indentation and flow syntax, quoting, duplicate keys (the spec requires unique keys in a mapping), and anchors that every alias actually resolves to. It does not check that the document matches your application's schema — required keys, expected value types, allowed enum values. A document can be perfectly valid YAML and completely wrong for Kubernetes; this tool answers the first question, and schema validation belongs with the tool that owns the schema.

Why is a duplicate key an error? My other parser just takes the last one.

Because the YAML specification says a mapping's keys must be unique, and parsers disagree about the fallback: some take the last value, some the first, some throw. A duplicated key usually means a merge went wrong — two blocks pasted into one file, an override appended instead of replaced — and the value your program reads depends on which parser reads it. This validator follows the spec and the parser it shares with the YAML Formatter: duplicates are reported with their location, so you fix the file instead of inheriting whichever behaviour your runtime happens to have.

My file has several documents separated by ---. Is that valid?

Yes — a multi-document stream is valid YAML, and this validator accepts it and counts the documents in its summary. That is the deliberate difference from this site's YAML converters (to CSV, Go, Java, Python, TypeScript), which refuse multi-document input: a stream is well-formed, but one conversion describes one document, and quietly converting just the first would misdescribe your file. Validity and convertibility are different questions, and the tools answer them accordingly.

How precise is the error location?

As precise as the parser can make it: syntax errors come with the line and column where the problem is detected, and an unresolved alias is reported at the alias itself. YAML parsers report the first error they meet, so fix the reported spot and validate again — a second error may be waiting behind it, especially with indentation, where one wrong line can make several later lines look wrong. That loop is normal, not a defect in your file beyond the spots themselves.

Why isn't my input auto-saved like on other tools?

Because YAML is usually configuration, and configuration files carry secrets — API keys, tokens, internal hostnames, database passwords. This validator keeps no draft of your input, in your browser or anywhere else: paste, validate, done. Refresh the page and the input is gone. That is deliberate, and it is the same rule on every YAML tool on this site.

The summary counts scalars — what is a scalar?

A scalar is a single value: a string, a number, a boolean, a null — the leaves of the document, as opposed to mappings (key/value collections) and sequences (lists). The counts are a fingerprint of the document you pasted: if the mapping and scalar counts are wildly different from what you expected, you probably pasted the wrong file or a truncated one, and it is better to notice that here than in production.

Related tools