YAML Validator
Catches the Norway problem, indentation surprises, and duplicate keys. Convert between YAML and JSON in one click.
Paste YAML on the left and click Validate,
or press Ctrl+Enter.
You can also drag & drop a .yml or .yaml file.
Learn More
YAML (YAML Ain't Markup Language) is a human-readable data serialization format commonly used for configuration files and data exchange. Unlike JSON or XML YAML uses indentation and whitespace to define structure rather than brackets or tags making it exceptionally clean and easy to read. YAML was first proposed in 2001 and has become the standard configuration format for modern DevOps and cloud-native tools. Docker Compose files Kubernetes manifests GitHub Actions workflows Ansible playbooks and CI/CD pipeline definitions all use YAML. Its popularity in these tools stems from its readability — operations teams spend significant time reading and reviewing configuration files and YAML's minimal syntax reduces cognitive overhead. YAML supports all common data types: strings numbers booleans null values arrays (called sequences) and key-value maps (called mappings). It also supports multi-line strings with block scalars (using | for literal blocks or > for folded text) anchors and aliases for reusing repeated values and comments (starting with #) — a feature notably missing from JSON. YAML files typically use the.yaml or.yml extension. While both are valid.yaml is the officially recommended extension according to the YAML specification.
YAML prioritizes human readability above all else. Its indentation-based syntax eliminates visual clutter from brackets and commas making complex nested configurations easy to scan. However YAML's flexibility comes at the cost of complexity — it supports features like anchors aliases and multiple document streams that can confuse newcomers. JSON is the universal data interchange format. Every programming language can parse it natively it has no ambiguity in its syntax and its strict rules make it predictable. JSON is ideal for API responses data storage and machine-to-machine communication. Its main weakness for human editing is the lack of comments and the verbose syntax for deeply nested structures. TOML (Tom's Obvious Minimal Language) occupies a middle ground. It uses a flat INI-file-inspired syntax with explicit section headers ([section]) that avoids YAML's indentation sensitivity and JSON's bracket nesting. TOML excels for simple configuration files — Rust's Cargo.toml and Python's pyproject.toml are prominent examples. However TOML becomes unwieldy for deeply nested or complex data structures. Use YAML for DevOps configuration and infrastructure-as-code. Use JSON for APIs and data interchange. Use TOML for simple application configuration. Each format has its sweet spot and choosing the right one depends on who will be reading and editing the file.
The most frequent YAML error is inconsistent indentation. YAML requires spaces (not tabs) for indentation and every level must use the same number of spaces. Mixing two-space and four-space indentation within the same file or accidentally inserting a tab character will cause a parse error that can be difficult to spot visually. Unquoted strings that look like other data types cause subtle bugs. The value yes is interpreted as a boolean true no as false and 3.0 as a float rather than a string. Norway's country code NO becoming false is a famous example. Always quote strings that could be ambiguous — use yes or 'yes' to ensure YAML treats the value as a string. Multi-line strings are another common source of errors. YAML provides multiple ways to handle multi-line text (| |- |+ > >- >+) each with different behavior for trailing newlines. Using the wrong style can add or remove newlines from your content unexpectedly. Duplicate keys are silently accepted by most YAML parsers — the last value wins. This means a typo that creates a duplicate key silently overrides your intended value with no error message. Colons in values without proper quoting incorrect list syntax (forgetting the dash and space) and encoding issues with special characters round out the most common pitfalls.
Frequently asked questions
Use YAML for files humans edit: Kubernetes manifests Docker Compose GitHub Actions Ansible playbooks CircleCI configs. It has comments multi-line strings anchors and readable nesting without brace noise. Use JSON for files machines generate/consume: API payloads logs config that's only read by code. YAML parses 5-10x slower than JSON is a superset of JSON (every JSON doc is valid YAML) and has more edge cases (see Norway bug FAQ). For new APIs always JSON.
An anchor defines a reusable value with &name; an alias references it with *name. Merge keys <<: *name merge an anchored map into another map. Example: define common container settings once as &common reuse in web/worker/cron services. Powerful but error-prone — they confuse linters obscure diffs and not all parsers support merge keys (YAML 1.2 removed them from the core spec). Use sparingly; prefer YAML's Jinja2/Helm templating for real reuse. Many teams explicitly ban anchors in their style guides.
YAML 1.1 (2005) treated a LOT of unquoted strings as booleans: yes no on off y n true false. The Norway bug came from a country-code list with NO: (Norway) being parsed as false: .... YAML 1.2 (2009) fixed this by only recognizing true/false/null as reserved. But many parsers still default to 1.1 — Node's js-yaml allows opting into SAFE mode (1.2 behavior) Python's PyYAML has a yaml.safe_load() alternative. Always quote string values that could be misparsed.
A single YAML file can contain multiple documents separated by ---. Kubernetes uses this heavily: one file multiple resources (Deployment Service Ingress) in a single kubectl apply. To parse: yaml.load_all() in Python or yaml.loadAll() in JS returns an iterator of documents. Each document is independent — anchors don't cross document boundaries. Useful for bundling related config but note that most IDEs and linters handle single-doc better than multi-doc.
YAML uses indentation as STRUCTURE like Python. Mixing tabs and spaces (or inconsistent space counts) changes the parse tree or throws. Rules: (1) only spaces never tabs; (2) consistent indentation per level (2 or 4 spaces pick one); (3) list items can align either with the key or indented one level deeper — both work pick a house style. The #1 source of YAML bugs is accidentally-inserted tabs from copy-paste — enable show invisibles in your editor and configure .editorconfig with indent_style = space.
More in Data Utilities
Developer validators, formatters and generators for structured data and identifiers.