Skip to main content

YAML Validator and Formatter Online

Check YAML syntax and inspect validation errors before editing a configuration file. Review the supported parsing options and formatted result.

YAML Validator & Formatter workspace

Line-Precise Errors

When something is wrong, we tell you exactly which line and exactly what — tab in indentation, duplicate key, unexpected dedent, missing colon. No "syntax error" mystery messages.

Round-Trip Formatting

Parse to a structured tree, then re-emit clean YAML with consistent 2-space indent. Strip out trailing whitespace, normalize quote styles, and lock in formatting before you commit.

Catches the Norway Problem

YAML 1.1 famously turns `no` and `off` into booleans. We surface what your strings parsed as so you can quote them before a multi-million-row config file sets every country code wrong.

100% Client-Side

Parsing happens in your browser. Kubernetes secrets, deploy keys, Ansible vaults — paste them with confidence. Your YAML never reaches our servers, ever.

Free Online YAML Validator & Formatter

Check YAML syntax and inspect validation errors before editing a configuration file. Review the supported parsing options and formatted result. Syntactically valid YAML is not necessarily valid application configuration. Kubernetes, GitHub Actions, Docker Compose, and other consumers apply their own schemas and rules. Validate against the target application's requirements after checking the YAML structure.

How to use the YAML validator

  1. Paste your YAML into the input box, or press Sample to load a real GitHub Actions workflow.
  2. Keep the Validate tab selected to check syntax — the result updates the instant you stop typing.
  3. Read the result: a green "YAML is syntactically valid" banner, or a single red error naming the exact line and reason.
  4. Switch to Format YAML to re-emit the document with consistent 2-space indentation so diffs show logic, not whitespace.
  5. Switch to Convert to JSON to see the parsed structure, then Copy or Download the output.

What is YAML and how does validation work?

YAML ("YAML Ain't Markup Language") is a human-readable data serialization format that uses indentation instead of braces to express hierarchy. It is the default config language for Kubernetes, GitHub Actions, Docker Compose, Ansible, GitLab CI, and AWS CloudFormation. The current spec is YAML 1.2.2 (October 2021), which made YAML a strict superset of JSON — every valid JSON document is also valid YAML.

This validator is a pragmatic YAML 1.2-subset parser. It walks the document line by line, tracking indentation depth to build the tree, and stops at the first structural problem with a clear message. It validates block mappings, block sequences, plain and quoted scalars, block scalars (| and >), comments, and the --- document separator. It deliberately rejects anchors (&), aliases (*), tags (!!str), and flow style ([a, b], {a: 1}) with an explicit error rather than half-parsing them.

"To maintain portability, tab characters must not be used in indentation, since different systems treat tabs differently."— YAML 1.2.2 specification, §6.1 Indentation Spaces

Worked examples: input → result

Valid · nested mapping

server: host: localhost port: 8080

Result: YAML is syntactically valid.

Invalid · tab in indentation

jobs: test: # leading tab, not spaces

Result: Line 2: YAML forbids tab characters in indentation — use spaces only.

Invalid · duplicate key

name: build name: deploy

Result: Line 2: Duplicate key "name" in mapping.

Edge case · the Norway problem

country: NO feature_flag: off

In a YAML 1.1 parser (PyYAML, js-yaml defaults), NO becomes the boolean false and off becomes false too — the famous Norway bug. This validator follows YAML 1.2, so both stay strings. To be safe in every parser, quote them: country: "NO".

YAML scalar type inference reference

These are the exact rules this validator uses to type an unquoted scalar. Anything that does not match a rule below stays a string. Quote a value to force it to a string regardless of its shape.

InputParsed typeNote
true / True / TRUEbooleanOnly these three spellings; yes/on stay strings (YAML 1.2)
null / ~ / (empty)nullAn empty value after a key also becomes null
42integerOnly if it fits a safe integer (≤ 2^53 − 1)
3.14floatLeading or trailing decimal accepted
NO / yes / offstringAvoids the Norway problem; quote anyway for 1.1 parsers
90210000000000000000stringToo large for a safe integer, so kept verbatim — no precision loss

The duplicate-key rule most validators get wrong

The YAML 1.2 spec calls duplicate mapping keys "implementation-defined", so most parsers silently keep the last value and throw the first away — a bug that hides until production. This validator instead hard-fails with Line N: Duplicate key, refusing to parse. It is the one place we are intentionally stricter than the reference parsers, because a silently dropped jobs: or env: block is exactly the kind of error that ships to a cluster unnoticed.

Two more deliberate guards: large integers like a 20-digit ID stay strings rather than losing precision past 2^53, and anchors, aliases, and tags raise an explicit error instead of being half-parsed. If you need full YAML 1.2 with anchors and flow style, run js-yaml server-side — this tool trades completeness for never corrupting your data quietly.

Last updated: September 15, 2026 · Runs 100% in your browser — no uploads, tool input is not sent to Toolk.

Frequently asked questions

What is the Norway problem, and how does this validator treat NO?

YAML 1.1 parsers coerce unquoted yes, no, on, and off to booleans, so the country code NO silently becomes false — the classic Norway bug. This validator follows YAML 1.2, under which those values stay strings; quoting them anyway (country: “NO”) keeps every parser happy.

Why does the tool refuse my anchors and flow-style arrays instead of parsing them?

It is a pragmatic YAML 1.2-subset parser that deliberately rejects anchors (&), aliases (*), tags (!!str), and flow style ([a, b] or {a: 1}) with an explicit error rather than half-parsing them. That trade favors never corrupting your config quietly; for full-spec documents run js-yaml server-side.

Do Kubernetes secrets or Ansible vault references get uploaded when I validate?

No. Parsing, formatting, and JSON conversion all execute locally in your browser tab, so tool input is not sent to Toolk — Toolk's page analytics never receive your configuration text — and validation continues to work offline once loaded.

My document parses here but fails in CI — what usually differs?

Two things to check: duplicate keys, which this validator hard-fails on but many parsers silently resolve by keeping only the last value, and scalar typing differences between YAML 1.1 and 1.2. After fixing either, convert the document with Toolk's JSON formatter (/tools/json-formatter) to inspect exactly what structure a downstream tool will see.

Need a different tool?

Browse all 103 browser-based tools (103 currently marked free), or tell us what useful utility we should build next.

Browse all tools