YAML Validator & Formatter

Your Docker Compose file won’t parse — docker-compose up says “yaml: line 15: mapping values are not allowed here.” You paste the YAML into a validator and instantly see: line 15 has a tab character instead of spaces. YAML’s whitespace-sensitivity means invisible errors are common, and you need a validator that pinpoints the exact location.

Why This Validator (Not the YAML Editor)

PureDevTools has a YAML Editor for full-featured editing with tree view and formatting. This tool is a focused YAML validator — paste YAML, see validation errors with line numbers, format with custom indentation, sort keys, and view the JSON equivalent. Use the editor for writing YAML; use this validator for quick syntax checks.

What Is YAML?

YAML (YAML Ain’t Markup Language) is a human-readable data serialization format widely used for configuration files, CI/CD pipelines, and data exchange. Its indentation-based structure makes it far more readable than JSON or XML for complex nested data.

Common uses of YAML include:

• Kubernetes manifests — Pod specs, Deployments, Services, ConfigMaps
• Docker Compose — multi-container application stacks
• GitHub Actions — CI/CD workflow definitions
• Ansible playbooks — infrastructure automation
• Application configuration — Rails database.yml, Symfony configs, Helm charts
• Static site generators — Jekyll front matter, Hugo configuration

# Example: GitHub Actions workflow
name: CI
on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: npm test

YAML Syntax Rules

Indentation

YAML uses spaces for indentation — never tabs. The number of spaces must be consistent within a document (2-space or 4-space are most common):

parent:          # top-level key
  child: value   # 2-space indent
  nested:
    deep: value  # 4-space total

Using a tab character instead of spaces causes a parse error. This validator detects tab-based indentation and reports the exact line.

Scalars: Strings, Numbers, Booleans, Null

YAML automatically coerces unquoted values to their types:

name: Alice          # string
age: 30              # integer
price: 9.99          # float
active: true         # boolean (also: false, yes, no, on, off)
nothing: null        # null (also: ~)
hex_color: "0x1F"    # quoted to prevent hex parsing

Boolean keywords — true, false, yes, no, on, off (case-insensitive) — are all parsed as booleans in YAML 1.1. Wrap them in quotes if you need the literal string:

feature_flag: "yes"  # string "yes", not boolean true

Quoted Strings

Use quotes when your string contains special characters or could be misinterpreted:

Block and Flow Style

YAML supports two notations for collections:

Block style (readable, multi-line):

servers:
  - host: web1.example.com
    port: 80
  - host: web2.example.com
    port: 8080

Flow style (compact, JSON-like):

servers: [{host: web1.example.com, port: 80}, {host: web2.example.com, port: 8080}]

This tool’s Style option controls when to switch:

• Block — always use block notation (best for readability)
• Mixed — block at the top level, flow for deeply nested objects/arrays
• Compact — all inline, produces the most compact output

Multiline Strings

YAML offers two block scalar indicators for multiline text:

# Literal block (|): preserves newlines exactly
description: |
  This is the first line.
  This is the second line.

# Folded block (>): folds newlines into spaces
summary: >
  This long text will be
  joined into a single line.

Common YAML Errors

Tab Indentation Error

This is the most common YAML mistake, especially when pasting from code editors configured for tab indentation:

# WRONG — tabs before "host" cause a parse error
server:
	host: localhost   # <- tab character

# CORRECT — use spaces
server:
  host: localhost   # <- 2 spaces

Unclosed Quote Error

# WRONG — missing closing quote
name: "Server Config

# CORRECT
name: "Server Config"

YAML Gotchas That Break Your CI/CD

These are real-world YAML pitfalls that pass syntax validation but cause runtime failures. This validator catches the syntax errors, but you need to know about these semantic traps too.

The Norway Problem

In YAML 1.1, country codes like NO (Norway) are parsed as boolean false:

countries:
  - US    # string "US"
  - GB    # string "GB"
  - NO    # boolean false — not the string "NO"!

Fix: Always quote country codes, feature flags, and any value that could be yes, no, on, off, true, or false:

countries:
  - "US"
  - "GB"
  - "NO"  # now it is the string "NO"

Version Numbers Become Floats

version: 3.10    # parsed as float 3.1 — the trailing zero is lost
version: "3.10"  # string "3.10" — correct

This breaks Docker Compose files (version: "3.8") and any config where 1.10 is not the same as 1.1.

Multiline String Trailing Newlines

# Literal block adds a trailing newline by default
script: |
  echo hello
  echo world
# Value is "echo hello\necho world\n" (note trailing \n)

# Use |- to strip the trailing newline
script: |-
  echo hello
  echo world
# Value is "echo hello\necho world" (no trailing \n)

The trailing newline causes subtle bugs in shell scripts, SQL queries, and template rendering.

Anchors and Aliases Can Cause Billion-Laugh Attacks

# This is valid YAML but expands to gigabytes of data
a: &a ["lol","lol"]
b: &b [*a,*a]
c: &c [*b,*b]
d: &d [*c,*c]
# ... each level doubles the size

If you accept YAML from untrusted sources, always set a maximum document size limit in your parser.

YAML vs JSON: Key Differences

The JSON Equivalent panel in this tool converts your YAML to JSON, which is useful when you need to pass configuration to a system that only accepts JSON.

Formatting YAML Files

The formatter parses your YAML and re-serializes it with clean, consistent indentation. This is useful for:

• Normalizing indentation — convert inconsistent 3-space or 6-space indents to standard 2 or 4 spaces
• Reviewing structure — the formatted output makes nesting levels immediately clear
• Diff-friendly output — sorted keys + consistent formatting eliminates spurious diffs in version control

Sort Keys

The Sort Keys option sorts all object keys alphabetically at every nesting level. Before sorting:

zebra: last
apple: first
mango: middle
  zub: nested-z
  ant: nested-a

After sorting:

apple: first
mango: middle
  ant: nested-a
  zub: nested-z
zebra: last

Sorted keys are especially useful for Kubernetes manifests and Helm values where consistent key order makes code review easier.

Frequently Asked Questions

Does formatting preserve YAML comments? No. Comments are not part of the parsed YAML data structure, so they are lost during the format/round-trip process. If you need to keep comments, use a dedicated YAML formatter that understands the comment positions (such as prettier with a YAML plugin).

Can I use this validator for Kubernetes YAML? Yes. Kubernetes manifests are standard YAML, and this validator correctly parses nested objects, sequences, and string scalars. However, it does not validate Kubernetes-specific schema rules (required fields, valid API versions). For schema validation, use kubectl --dry-run=client -f manifest.yaml or a dedicated Kubernetes linter like kubeval.

What is the difference between YAML 1.1 and YAML 1.2? YAML 1.1 treats yes, no, on, off as booleans. YAML 1.2 (released 2009) restricts booleans to true and false only, making YAML a proper superset of JSON. Most tools (including Docker Compose) still use YAML 1.1 behavior. This tool uses YAML 1.1 coercion rules.

Why does my number get quoted in the output? If a string value looks like a number (e.g., "1.0" or "0x1F"), the formatter automatically adds quotes to prevent YAML parsers from misinterpreting it as a numeric type. This is correct behavior.

Is this tool safe for sensitive configuration? Yes. The validator and formatter run entirely in your browser — no data is transmitted to any server. Your API keys, database passwords, and other secrets stay on your device.