Format, validate and clean up YAML in seconds

Why YAML formatting turns into its own little chore

Here's the thing nobody tells you when you start writing YAML: it looks so simple that you stop being careful, and that's exactly when it breaks. There are no brackets to close, no semicolons to forget. It's just indentation, colons, and dashes. Which is great, until you're six levels deep in a Kubernetes deployment file at 11pm and one line is indented by three spaces instead of two, and the whole thing throws an error that says something like "mapping values are not allowed here" — which, respectfully, means almost nothing on its own.

That's really the core problem with YAML. It's readable when it's written well, and it's a nightmare when it isn't, and there's no compiler yelling at you in real time the way there is with most programming languages. You usually find out something's wrong only when you try to run it — deploy the manifest, kick off the workflow, start the container — and it fails somewhere downstream of where the actual typo is.

So a formatter isn't really a "nice to have" for YAML the way it might be for, say, CSS. It's closer to a spell-checker you actually need. You paste in whatever you've got, it tells you immediately if something doesn't parse, and if it does parse, it cleans up the spacing so the file actually looks like something a human wrote on purpose.

What actually happens when you hit "Format"

Behind the two panes above, the tool is doing two separate jobs, and it's worth knowing the difference. First, it tries to parse your YAML — turn it into an actual in-memory structure of maps, lists, strings and numbers, the same way a script that reads your config file would. If that step fails, that's when you see the red status with a line and column number, because the parser knows exactly where it got confused.

If parsing succeeds, the second job is printing it back out with consistent rules: a fixed indent size (2 or 4 spaces, your choice), consistent quoting, and no leftover whitespace at odd depths. That's why formatting can sometimes change how your file looks even though it didn't change what it means — the data structure is identical, only the presentation is normalized. If you want to go one step further and see that structure as plain JSON instead, the YAML → JSON button does the same parse step and just prints it differently.

A few things that trip people up, in no particular order

• Tabs. YAML doesn't allow tab characters for indentation, full stop. If you copy-pasted from a Word doc or an old Notepad file, there's a good chance a tab snuck in. Our indentation guide covers this in more depth.
• Colons inside plain strings. Writing time: 10:30 unquoted can confuse the parser, because a colon usually means "this is a new key." Quoting it as time: "10:30" fixes it instantly.
• Inconsistent sibling indentation. Two keys at the same level need to start at the exact same column. It's an easy thing to break when you're editing by hand and your editor doesn't show whitespace.
• Anchors and aliases used incorrectly. These are the &name and *name shortcuts YAML uses to avoid repeating blocks. They're powerful but easy to misuse — we go through them properly in this anchors and aliases guide.

None of these are exotic. They're the kind of small, physical mistakes anyone makes when a file is mostly whitespace — which is exactly why having something that instantly flags the line is more useful for YAML than it is for almost any other format.

Where you'll actually run into YAML

If you've never sat down and "learned YAML" on purpose, that's normal — most people back into it. It shows up as the format underneath other tools rather than something you choose. docker-compose.yml files, Kubernetes manifests, GitHub Actions workflows in .github/workflows/, Ansible playbooks, CI configs for GitLab and CircleCI, even the front matter at the top of a lot of static-site blog posts — it's quietly everywhere in modern infrastructure and tooling. We've written a short, practical piece on each of these in the blog, so if you're stuck on one specific use case, that's a faster read than a general YAML tutorial.

The honest pitch for this page is pretty simple: paste your YAML in, get a clear answer about whether it's valid, get it cleaned up if it is, and don't have to think about where that data went afterward. That's really all a formatter needs to do well.