YAML Validator

Paste YAML and find out whether it is valid, with the exact line and column of any error explained in plain language. Then the whitespace problems, and the handful of unquoted values that change type on you without warning.

Paste below, or drop a file anywhere on this panel

Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.

The answer appears here

Paste on the left and press Validate. Nothing leaves this tab.

Examples

Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.

The Norway problem

Unquoted yes and NO become booleans, and a version number loses precision

on: yes
version: 1.0
country: NO

Inconsistent indentation

A list indented two ways, which parses as something other than it looks like

a: 1
b:
 - x
  - y

Common mistakes

These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.

  1. Leaving yes, no, on and off unquoted

    YAML 1.1 reads them as booleans, so country: NO becomes false. This is the Norway problem and it is still live in most parsers.

    Instead:Quote any string that could be read as a boolean.

  2. Writing a version as an unquoted number

    1.0 becomes the number 1 and 1.10 becomes 1.1. Version numbers are strings.

    Instead:Quote them.

  3. Mixing tabs and spaces

    YAML forbids tabs for indentation entirely, and the parse error is often reported on a later line.

    Instead:Spaces only. Configure the editor to convert.

What it checks

A parse error is the urgent problem and every YAML parser reports it badly. After that come the values that parse fine and mean something else.

Syntax errors, translated

The parser's terse reason turned into an explanation with a likely cause, plus an excerpt with a caret under the character. Bad indentation, tabs, unclosed quotes, duplicate keys and a stray colon in an unquoted value each get their own wording.

Rules that survive a parse failure

The whitespace and style checks read the raw lines and never parse anything, so a file that fails to load still reports the tab on line 12. That is exactly when you want to hear it.

Values that change meaning

Unquoted NO, yes, on and off become booleans in YAML 1.1 parsers, which includes the Go library Kubernetes uses. 0644 becomes the number 420. A version of 1.10 becomes 1.1 and the zero is gone for good.

Whitespace and encoding

Tabs in indentation, which YAML forbids outright. Indentation that is not a multiple of the file's own step, or that jumps a level. Trailing whitespace, Windows line endings, a byte order mark, and control characters that arrive invisibly from a terminal paste.

Why does YAML behave so strangely?

YAML was designed to be pleasant for humans to write, and most of its surprises come directly from that goal. It guesses what you meant. When the guess is right the file is lovely to read; when it is wrong the file is still valid YAML, parses without complaint, and means something you did not intend.

Unquoted values get type-guessed

An unquoted scalar is examined and converted. Something that looks like a number becomes a number, and a short list of words become booleans. This is why the string yes turns into true and why a version number written as 1.20 becomes the float 1.2, losing the zero. Quoting is the fix, and it is the only fix.

enabled:  yes        ->  true      (boolean, not the string "yes")
version:  1.20       ->  1.2       (float, the zero is gone)
build:    09         ->  error or 9 depending on the YAML version
answer:   no         ->  false

quote them and every one of these stays a string

The Norway problem

In YAML 1.1, the country code NO parses as the boolean false. A list of country codes therefore silently turns one entry into a boolean, and the file is perfectly valid. YAML 1.2 narrowed the boolean set to true and false only, but plenty of parsers still run 1.1 semantics, including some in wide use, so the behaviour depends on the library, not on your file.

countries: [DK, NO, SE]   ->  ["DK", false, "SE"] under YAML 1.1

countries: ["DK", "NO", "SE"]   correct under every version

Tabs are illegal, and the error says something else

YAML forbids tabs for indentation entirely. Editors that helpfully convert leading spaces to tabs produce a file that fails to parse with a message about a mapping value or an unexpected token, pointing at a line that looks fine. The rule is simple: spaces only, but the diagnostics rarely say so, which is why this tool reports the tab and its exact position instead.

The three multi-line forms are not interchangeable

A pipe keeps the newlines, a greater-than folds them into spaces, and adding a minus strips the trailing newline. The difference matters most in the places YAML gets used for embedding other formats: a certificate or a private key folded with a greater-than is corrupted, and a shell script that loses its final newline can fail in ways that are hard to trace back here.

literal: |        keeps every newline        -> "a\nb\n"
  a
  b

folded:  >        newlines become spaces      -> "a b\n"
  a
  b

strip:   |-       keeps newlines, drops last  -> "a\nb"
  a
  b

More data tools

JSON Validator & Formatter Valid? And where exactly is it wrong? YAML to JSON Converter Either direction, and what it costs

Elsewhere on the site

Terraform Validator & Formatter Kubernetes YAML Generator Kubernetes YAML Validator AWS IAM Policy Validator & Analyzer