YAML Validator & Formatter

A tab anywhere in the indentation

YAML forbids tab characters for indentation. Spaces only, with no exceptions.

Editors insert them invisibly, and the error message ("found character that cannot start any token") never says "tab". If a line looks correctly indented and still fails, that is almost always what it is. Turn on "render whitespace" in your editor, or set it to insert spaces for YAML files.

Indentation that is inconsistent, not just wrong

Every key at the same level must have the same indent, and YAML does not care whether that is two spaces or four, only that it is consistent.

Mixing two and four spaces in one file parses as a deeper nesting level rather than as an error, so the document is valid and means something you did not intend. Formatting the output is how you see it.

A colon followed by a space inside a value

The : sequence is how YAML separates a key from a value, so it cannot appear unquoted inside one.

This bites on log formats, times and URLs with ports: message: error: timeout and cron: 0 5 * * * are the usual ones. Quote the whole value: message: "error: timeout".

no, yes, on and off becoming booleans

Under YAML 1.1, which most tools still follow, those words are booleans rather than strings.

This is the famous "Norway problem": a country list containing NO parses as false. It also hits ON, Y, N and any unquoted yes/no answer. Quote the value whenever a string that happens to be one of those words is what you meant.

A version number that is not a string

Unquoted numeric-looking values are parsed as numbers.

version: 1.20 becomes the float 1.2, and a leading zero such as 08 may be read as octal or rejected outright. Quote every version, every zero-padded number and anything that only looks numeric, such as a build ID.

Duplicate keys

The same key twice in one mapping.

Strict parsers reject it, but many accept it and silently keep the last one, which is worse: the file works and one of your two settings quietly does nothing. This validator flags it rather than picking a winner.

A list item at the wrong indent

A - may sit at the same indent as its key or one level in, but every item in the list has to agree.

One item indented differently from its siblings either ends the list early or nests it inside the previous item. The document still parses, so nothing tells you until whatever reads the file behaves oddly.

Multiple documents without a separator

One file may hold several YAML documents, separated by a line containing only ---.

Concatenating two Kubernetes manifests without that separator produces duplicate top-level keys rather than two objects, and kubectl apply sees only a broken single document. A trailing ... ends a document but is rarely needed.

Trailing whitespace in a block scalar

A | block keeps newlines; a > block folds them into spaces.

Trailing spaces at the end of a line inside a | block survive into the value, which breaks embedded scripts and certificate blocks in ways that are nearly invisible in review. Use |- to strip the final newline when the consumer does not want one.

A special character starting a plain value

Several characters are reserved when they begin a value: @, backtick, %, &, *, !, |, >, {, [ and # after a space.

A password beginning with * or a template starting with {{ fails to parse and the message points at the character rather than explaining the rule. Quote the value and the problem disappears.

Is this a Kubernetes YAML validator?

Yes. It detects a Kubernetes manifest from its apiVersion and kind, then validates Deployments and Services against the v1.29 schemas, so it catches a misspelled field or a wrong type, not just broken indentation. Everything runs in your browser, so a manifest with real hostnames or secrets in it never leaves the page. It is not a substitute for kubectl apply --dry-run=server, which is the only check that knows about your cluster.

What is a YAML validator?

It parses your YAML the way the tools that consume it will, and reports the first thing that stops it being a valid document, with the line number where the parser gave up. That covers indentation, tabs, unquoted special characters, duplicate keys and malformed lists. It checks that the file is well-formed YAML; it does not check that the contents are a valid Kubernetes object or a valid Compose file, which is a separate question.

Why is my YAML invalid when it looks fine?

In order of how often it happens: a tab character in the indentation, an unquoted : inside a value, inconsistent indent depth between sibling keys, and a value starting with a reserved character such as * or {. The parser reports where it failed rather than where you went wrong, so check the two lines above the one it names.

Does YAML allow tabs for indentation?

No, and this is the single most common cause of an invalid YAML file. YAML uses spaces only. A tab is legal inside a quoted string but never in the indentation, and the error message does not tell you a tab is the problem, which is why it costs people so much time.

Can I use this to validate a Kubernetes manifest?

Yes for the YAML itself, including multi-document files separated by ---. It will not tell you whether the manifest is a valid Kubernetes object, because that depends on the API versions your cluster serves. Run kubectl apply --dry-run=server -f file.yaml for that, or build the manifest with the [Kubernetes YAML generator](/tools/kubernetes-yaml-generator) so the structure is right to begin with.

What is the Norway problem in YAML?

YAML 1.1 treats yes, no, on, off, y and n as booleans. A list of country codes containing NO therefore parses as false instead of Norway. YAML 1.2 removed this, but most parsers in wide use still behave the 1.1 way, so quote any string that happens to be one of those words.

Is my YAML uploaded anywhere?

No. The parsing happens in your browser. Nothing is sent to a server, logged or stored, which is the reason this is safe to use on a manifest that contains internal hostnames or a Secret.