YAML Formatter: Format, Validate & Minify YAML Online
YAML (YAML Ain't Markup Language) is everywhere in modern DevOps and software configuration. Docker Compose, Kubernetes, GitHub Actions, Ansible — they all use YAML. But YAML's reliance on whitespace makes it uniquely unforgiving: a single misplaced space or tab can break an entire deployment. Our free YAML Formatter catches those errors before they reach production.
Where Is YAML Used?
You will encounter YAML in virtually every modern infrastructure and development tool:
- • Docker Compose — Defines multi-container application stacks with services, networks, and volumes
- • Kubernetes — Describes pods, deployments, services, config maps, and every other resource
- • GitHub Actions — Defines CI/CD workflow triggers, jobs, and steps
- • Ansible — Automates server configuration and application deployment via playbooks
- • Helm charts — Packages Kubernetes applications with templated YAML manifests
- • App configuration — Rails, Jekyll, ESLint, Prettier, and countless other tools store configuration in YAML
YAML Syntax Basics
YAML represents data using key-value pairs, lists, and nested structures defined by indentation. Here is a Docker Compose example that demonstrates the main concepts:
version: "3.9"
services:
web:
image: nginx:latest
ports:
- "80:80"
environment:
NODE_ENV: production
PORT: 3000
db:
image: postgres:15
volumes:
- pgdata:/var/lib/postgresql/data
volumes:
pgdata:
Key syntax rules in YAML: keys and values are separated by a colon and space (key: value). List items start with a dash and space (- item). Comments start with #. Nesting is defined by consistent indentation — typically 2 spaces per level.
Common YAML Mistakes
- Tabs instead of spaces (the #1 mistake) — YAML explicitly forbids tab characters for indentation. Only spaces are allowed. Most parsing errors in YAML trace back to a stray tab character inserted by an editor. Configure your editor to use spaces for YAML files.
- Inconsistent indentation — If you use 2 spaces for one block and 4 spaces for another, the parser will reject the file. Pick one indentation size and stick to it throughout the entire document.
- Forgetting the space after a colon — key:value is not valid YAML. It must be key: value with a space after the colon.
- Unquoted special characters — Values containing : # [] {} | > * or that look like numbers/booleans but should be strings need to be quoted. For example, version: "3.9" should stay quoted to ensure it's treated as a string.
- Duplicate keys — YAML technically allows duplicate keys but the behavior is undefined. Most parsers use the last value, silently discarding earlier ones. Validate your YAML to catch accidental duplicates.
YAML vs JSON: When to Use Which
| Feature | YAML | JSON |
|---|---|---|
| Comments | Yes (#) | No |
| Human readability | High | Medium |
| Parse speed | Slower | Faster |
| API/data transfer | Rare | Universal |
| Config files | Preferred | Sometimes |
Validate and format your YAML instantly
Paste your YAML, catch errors immediately, and download clean output
Open YAML Formatter →Frequently Asked Questions
What is YAML used for?
YAML is primarily used for configuration files and data serialization in human-readable format. It powers a huge range of tools in modern software development: Docker Compose files define multi-container applications in YAML; Kubernetes manifests describe pods, services, and deployments; GitHub Actions workflows define CI/CD pipelines; Ansible playbooks automate server provisioning; Helm charts configure Kubernetes applications; and countless frameworks use YAML for app configuration (Rails database.yml, Jekyll site config, ESLint config, etc.). Its readability advantage over JSON makes it the preferred choice whenever a human will frequently read or edit the configuration.
Why does YAML not allow tabs?
This is the single most-asked YAML question and the source of countless errors. YAML uses indentation to define structure, but the YAML specification explicitly prohibits tab characters for indentation — only spaces are allowed. The reason is that tabs are ambiguous: different editors interpret a tab as 2, 4, or 8 spaces wide, meaning the same file can parse differently depending on the tool. By mandating spaces only, YAML ensures consistent interpretation across all parsers and editors. Most modern editors can be configured to automatically convert tabs to spaces; in VS Code, check the bottom status bar for 'Spaces' vs 'Tabs' and switch accordingly.
What is the difference between YAML and JSON?
YAML and JSON represent the same kinds of data (key-value pairs, arrays, strings, numbers, booleans, null) but with different syntax priorities. JSON is optimized for machines — it's stricter, requires double quotes around all strings and keys, and has no support for comments. YAML is optimized for humans — it's more relaxed (strings don't always need quotes), supports comments with #, and uses whitespace indentation instead of braces and brackets. JSON is generally preferred for APIs and data transmission because it's faster to parse and more universally supported. YAML is preferred for config files that humans maintain regularly. Importantly, valid JSON is also valid YAML — YAML is a superset of JSON.
How do I validate YAML?
The fastest way is to use our online YAML Formatter — paste your YAML and it will immediately report any syntax errors with the line number where the problem occurs. Common validation errors include: mixing tabs and spaces (always use spaces only), incorrect indentation levels (child keys must be indented more than their parent), unquoted strings that contain reserved characters like : or #, and mismatched list item indentation. For automated validation in CI/CD pipelines, tools like yamllint (Python) can lint YAML files and enforce style rules. Most code editors also have YAML extensions that provide real-time validation as you type.
What does 'indentation error' mean in YAML?
An indentation error in YAML means the parser found a key or value at an indentation level it did not expect. YAML is strict about indentation: sibling keys must be at the same level, and child keys must be indented exactly consistently (e.g., always 2 spaces or always 4 spaces — mixing within a file causes errors). Common triggers include: accidentally adding an extra space before a key, copy-pasting content from a source that uses different indentation, mixing tabs and spaces, or forgetting that list items (starting with -) also consume one indentation level. When you see this error, compare the failing line's indentation to its neighboring lines carefully.