Developer Tools·4 min read

YAML Validator: Fix Indentation and Syntax Errors

YAML is easy to read and easy to break. One extra space moves a key into the wrong mapping, a tab stops the parser outright, and an unquoted no can turn into false depending on which tool reads the file. A validator catches the syntax errors before your deploy does, and a good one also points out the lines that parse fine but mean something other than what you intended. This guide covers both, with the errors you are most likely to see and how to fix each one.

Open the free YAML Validator All insights

Why YAML fails where JSON wouldn't

Whitespace carries meaning.

JSON marks structure with braces and brackets, so indentation is decoration. YAML has no braces in block style; indentation is the structure. A key indented four spaces belongs to the mapping above it, and a key indented five spaces is, as far as the parser is concerned, something else entirely. That makes YAML pleasant to write and review, and fragile to edit by hand.

YAML also types unquoted values for you. 10 is a number, true is a boolean, 2024-01-15 is a date and ~ is null. That saves quotes but means a value can change type without anyone noticing, which is where the subtler bugs come from.

Validating a file in a few seconds

Paste and read.

Paste the YAML into the YAML Validator, drop the file on the editor, or press Load URL for a raw file on GitHub or another public address. Validation runs as you type. A broken file highlights the failing line in red and shows the line, the column, a plain-English reason and a snippet of the surrounding lines. Go to error moves the cursor to the exact spot.

A valid file shows how many documents it contains, since Kubernetes manifests and some CI files hold several separated by ---. Below that, the Formatted YAML tab re-prints the data with consistent indentation, and the As JSON tab shows exactly what a program will receive, which settles most arguments about what a value really is.

The errors you'll see most

And what each one really means.

Parser messages are terse, so the validator rewrites the common ones. These cover most broken files.

Bad indentation of a mapping entry: a key does not line up with its siblings, or the line above is missing a colon. Count the spaces; one too many is enough.
Tabs are not allowed for indentation: the file was edited in something that inserts tabs. Replace them with spaces, usually two per level.
Duplicate key: the same key appears twice in one mapping, often after a copy and paste. Tools disagree about which copy wins, so remove one.
A quoted string is never closed: a missing quote swallows everything up to the next quote in the file, so the reported line can be far below the real mistake.
Unidentified alias: *name is used before &name defines it. Move the anchor above the first alias.

Legal YAML that still causes bugs

Warnings, not errors.

Some lines parse without complaint and still bite. The validator lists them as style warnings, each linked to its line, so you can decide whether to quote the value.

The most famous case is the Norway problem. YAML 1.1 reads unquoted yes, no, on and off as booleans, so a list of country codes that includes NO turns into false. YAML 1.2, which this validator follows, keeps them as text, but plenty of tools in production still use 1.1 rules. Numbers with a leading zero such as 0755 can be read as octal, and times such as 22:22 can be read as base-60 numbers by 1.1 parsers, which famously breaks unquoted port mappings in Compose files. Mixed indentation, such as two spaces in one block and three in another, is legal but makes the next edit risky.

Kubernetes, Compose and CI files

Syntax first, then schema.

A YAML validator checks that the file is well-formed and warns about risky values. It does not know that a Deployment needs spec.template or that Compose calls the key ports and not port. Once the syntax is clean, run the tool's own check: kubectl apply --dry-run=client -f file.yaml for Kubernetes, docker compose config for Compose, and the linter your CI provider offers for pipeline files.

Two settings help with real-world files. The Schema menu switches between full YAML 1.2 with merge keys and dates, the plain 1.2 core schema, the strict JSON schema and Failsafe, where every value stays a string. Allow duplicate keys makes the last value win instead of failing, which matches how some older tools behave.

Habits that keep YAML valid

Pick one indent width, usually two spaces, and set your editor to insert spaces for the Tab key. Quote values that must stay strings, such as version numbers, postcodes and country codes. Keep one idea per file where you can, and validate before every commit rather than after a failed deploy.

When a file is generated by a script, the Formatted YAML tab is a quick way to normalize it, though it drops comments and expands anchors, so keep your hand-written original as the source. Everything runs in your browser, so secrets in config files never leave your machine. For conversions, YAML to JSON and JSON to YAML use the same parser with more output options.