Fix your YAML before it breaks your deployment
YAML is whitespace-sensitive. One wrong indent and your Kubernetes pod spec puts the env vars under the wrong container. Three spaces instead of two and your Docker Compose service inherits the wrong network. YAML doesn’t tell you something is wrong, it just interprets your mistake differently than you intended.
This formatter normalizes everything: consistent 2-space indentation (the standard), cleaned-up trailing whitespace, uniform key: value spacing. Comments are preserved. Paste your messy YAML, get clean YAML back.
The places YAML goes wrong
Mixed indentation. One person uses 2 spaces, another uses 4, someone copy-pasted a snippet with tabs. The file still parses, but the structure might not be what anyone intended.
Trailing whitespace. Invisible characters after a value can cause subtle issues. Some YAML parsers are forgiving. Others aren’t.
Inconsistent key-value spacing. key:value, key: value, key: value, they all parse the same way, but inconsistency makes the file harder to scan visually.
When to format
Before docker-compose up. Before kubectl apply -f. Before git commit. Basically, before any tool reads your YAML, format it first.
Docker Compose: after editing services, volumes, and networks, formatting catches indentation issues before they cause mysterious container behavior.
Kubernetes manifests: a misindented field in a K8s manifest can silently create a valid-but-wrong resource. Format first, apply second.
CI/CD pipelines: GitHub Actions, GitLab CI, CircleCI workflows with multiple jobs and steps get complex. Formatting keeps them readable.
Ansible playbooks: large playbooks with nested tasks and handlers benefit from consistent formatting.
Team collaboration: when five people edit the same YAML file, formatting before committing prevents whitespace diffs from cluttering the PR.
YAML formatting rules to live by
Always 2-space indentation. It’s the standard across Kubernetes, Docker Compose, GitHub Actions, and most YAML tools. Tabs are not allowed by the YAML spec.
Quote strings with special characters. Unquoted strings containing colons, brackets, or things that look like booleans (yes, no, true) will surprise you.
Validate after formatting. Formatting fixes whitespace, not logic. Wrong key nesting or incorrect data types need manual attention.
For converting between YAML and JSON, there’s the YAML to JSON and JSON to YAML converters.
FAQ
What does it normalize?
Indentation to 2 spaces per level, removes trailing whitespace, ensures consistent key: value spacing.
Does it preserve comments?
Yes, comment lines starting with # are kept as-is.
Can it fix syntax errors?
No, it normalizes whitespace and formatting. Structural errors like missing colons or wrong nesting need manual fixing.
Why is indentation so critical in YAML?
YAML uses indentation to define hierarchy, there are no brackets or braces. A line indented wrong belongs to a different parent, which changes the document’s meaning entirely.
Client-side?
Yes, your YAML stays in your browser. Safe for files with secrets and infrastructure details.