This tool checks whether a string is valid YAML in your browser; nothing leaves your machine. The tool runs syntactic validation — does it parse — not schema validation against a specific structure.

What syntactic validation checks

A YAML parser walks the input and confirms it follows YAML grammar:

Indentation is consistent within each block (no mixed tabs and spaces; no inconsistent indent).
Mappings and sequences are well-formed.
Strings are properly quoted (where quoting is needed).
Block scalars (| and > syntax) are properly indented.
Anchors and aliases reference existing names.

The tool above runs the input through a YAML parser and reports either “valid” or the parse error and approximate position.

Common YAML errors

Error	What it means
`mapping values are not allowed in this context`	Usually a missing space after `:` or a `:` that isn’t being parsed as a mapping separator.
`expected <block end>`	Indentation problem — closing of a block isn’t where the parser expected.
`found character '\t' that cannot start any token`	Tab character in indentation (forbidden in YAML).
`found undefined alias`	`*name` referencing an anchor that doesn’t exist (or comes later in the document).
`mapping has duplicate key`	Two keys with the same name in the same mapping. Some parsers reject; some silently keep the last.
`could not find expected ':'`	A line that looks like part of a mapping but is missing the `:`.

The tool above surfaces the position of the error so you can find it.

Indentation rules

YAML is indentation-sensitive (like Python). Rules:

Children are indented further than their parent.
Siblings have the same indentation.
Tabs are forbidden in indentation.
Spaces only, in any consistent number per nesting level.

parent:           ← 0 indent
  child1: value   ← 2 indent (child of parent)
  child2:         ← same as child1
    grandchild: x ← deeper than child2
parent2:          ← back to 0 indent
  child: y

The most common indentation error: mixing 2-space and 4-space indent in the same file. Most parsers accept any consistent indent within a block but break when one block uses 2 and a sibling uses 4.

Type-detection traps

YAML’s “let me figure out the type” approach catches many users. Examples that parse but produce surprising values:

country: NO              # → false (YAML 1.1 boolean)
zip: 00501               # → 501 (leading-zero number)
version: 1.10            # → 1.1 (trailing-zero number)
status: yes              # → true (YAML 1.1 boolean)
date: 2025-01-15         # → Date object in many parsers
hex: 0xff                # → 255 (hex number)
octal: 010               # → 8 in YAML 1.1, 10 in YAML 1.2
empty:                   # → null (not empty string)

These pass syntactic validation. Whether they’re “correct” depends on what you intended. The tool above only checks syntax — it doesn’t warn about scalars like these — so quote any value you need to stay a string. (It parses with YAML 1.2 rules, under which NO and yes are plain strings; YAML 1.1 parsers such as PyYAML still read them as booleans.)

Schema validation

Beyond “does it parse” is “does it match the expected schema.” YAML doesn’t have a built-in schema language — but JSON Schema works on YAML once the YAML is parsed:

# Schema (in JSON, but applicable to YAML data):
{
  "type": "object",
  "properties": {
    "name": { "type": "string" },
    "age":  { "type": "integer", "minimum": 0 }
  },
  "required": ["name"]
}

For complex YAML configs (Kubernetes, GitHub Actions, OpenAPI specs), the consuming system has its own schema. Tools like:

yaml-language-server — provides schema-aware validation in editors (VS Code, etc.).
yamllint — CLI tool for style and basic structural checks.
ajv + JSON Schema — convert YAML to JSON, then validate against a JSON Schema.
CRD/OpenAPI validation tools — for Kubernetes specifically.

Multi-document validation

YAML files can contain multiple documents separated by ---. A multi-document file is valid if each document parses; the tool above reports how many documents it found and what each one contains, or the first error with its line and column.

When the validator passes but data is wrong

Syntactic validation only checks the parse. The values can still be:

Wrong types that happen to parse as something. port: 8080 is a number; if your code expects a string, you get a type error at runtime.
Wrong values. port: -1 is valid YAML; semantically wrong.
Missing required keys. {} is valid YAML; your consumer may need specific keys.
Invalid for a specific schema. {} parses but doesn’t match a Kubernetes Pod schema.

For all of these, you need schema validation, not just syntactic.

Common pitfalls

Tabs in indentation. Most YAML parsers reject tabs immediately. Most editors auto-convert tabs to spaces; some don’t. Configure your editor.
Inconsistent indent within a block. Sibling items at 2 and 4 spaces in the same parent break parsing.
Unquoted strings that auto-coerce. Especially NO, yes, null, dates, version numbers. Quote when in doubt.
Duplicate keys. Most parsers silently keep the last value; some reject. Check the consumer.
Trailing whitespace on lines with > or |. Block scalars are sensitive to ending. Strip trailing whitespace.
Encoding issues. UTF-8 is the modern default. UTF-16 with BOM works in some parsers but not all.
Anchor before reference. *alias must come after &alias. Forward references aren’t allowed.

For the YAML-to-JSON conversion, see YAML to JSON. For JSON validation, JSON validator.

YAML Validator