Format YAML on the document itself so comments, anchors and multi-document structure survive — with strict validation that refuses duplicate keys and reports errors by line and column. Free, no sign-up — runs locally in your browser.
Why YAML needs a careful formatter
YAML is whitespace-significant, comment-carrying and
anchor-aliasing — three properties that make naive formatting
dangerous. Re-print a YAML file through a JSON-style value
model and you lose the comments your team wrote for each
other, collapse the anchors that keep a Kubernetes manifest
DRY, and occasionally change a scalar's meaning outright.
This formatter works on the document itself, using the
yaml package's document API, so formatting is a
layout operation rather than a data conversion: indentation
and alignment change; keys, comments, anchors and document
boundaries do not. And because the parse is strict, the same
pass doubles as a validator that catches duplicate keys —
the error most likely to be silently eating one of your
settings right now.
How to use this tool
- Paste the YAML, upload a
.yaml/.yml file, or drop one onto the panel. - Choose the indent width your project uses — 2 spaces is the community norm, 4 if your house style says so.
- Press Format YAML. The result reports the document count, so multi-document streams are accounted for, and your original text is left untouched in the input box.
- Validate only gives the ✓/✗ verdict without producing output — handy mid-edit, and its error messages carry the line and column of the first problem.
- Copy or download the result. Note the tool does not auto-save drafts: configuration YAML often holds things that should not linger in a browser's storage.
What the strictness buys you
A formatter that re-prints your file performs a full parse
first — the perfect moment to refuse the constructs that
other parsers handle by guessing. Duplicate keys (rejected,
with both locations), tabs in indentation (rejected,
positioned), unresolvable aliases and unclosed flow
collections all stop the run with an explanation, instead of
passing silently into a formatted file that looks clean and
behaves differently. One honest caveat: scalar styling is the
serialiser's call — a string that must be quoted to stay a
string will gain quotes, and a long plain scalar may be
re-wrapped. The value never changes; the spelling sometimes
does, and only where the plain spelling would be ambiguous
to another parser.
Worked example
This service definition, with wandering indentation and a duplicated key:
service:
name: billing
replicas: 3
replicas: 5
# primary region
region: eu-west-1
fails with a positioned error naming both
replicas lines — the formatter refuses to guess
whether you meant 3 or 5. Remove the stray line and the same
input formats, comment intact, to clean two-space nesting:
service:
name: billing
replicas: 3
# primary region
region: eu-west-1
Frequently asked questions
What does formatting actually change in my YAML?
Indentation is normalised to the width you pick, sequences and mappings are re-aligned, and scalars may be re-quoted when the serialiser decides the plain spelling would be ambiguous (a string like "yes" or "0123" cannot stay bare in YAML 1.1-flavoured parsers without changing its meaning). Keys, values, order, anchors, aliases and comments are preserved. What the formatter will never do is go through a JavaScript object the way the JSON-to-YAML converter does — formatting works on the document itself, which is exactly why comments and anchors survive it.
Why did it reject YAML that another tool accepted?
Most often: duplicate keys. Many parsers silently let the second occurrence of a key overwrite the first — a configuration footgun where the file says two things and one is quietly ignored. This formatter uses the yaml package in strict mode, where a duplicate key is an error with the line and column of both occurrences, because a formatter that re-prints your file is the last chance to notice. The other usual suspects are tabs used as indentation (YAML forbids them), a bad anchor reference, and flow collections left unclosed — each reported with its position.
What happens to multi-document YAML?
Each document is formatted independently and the documents are re-joined with the standard --- separators, in their original order, with the document count reported under the result. Kubernetes manifests, Helm output and GitHub Actions matrices are the usual multi-document cases. A document that fails to parse fails the whole run with its error position — the tool never formats half a stream and hands it back as if it were whole.
Can I use this just as a validator?
Yes — validation is the first thing the format operation does. Paste, press Format, and a ✓ message with the document count means the YAML parses cleanly under a strict parser; an error message gives the line and column of the first problem. Since the check runs entirely in your browser, it is safe for configuration files you would not paste into a server-side tool — CI secrets files, kubeconfigs and the like never leave the page. The YAML you paste is also never auto-saved as a draft (unlike most tools here), because YAML in the wild is configuration more often than prose.
How is this different from the YAML to JSON converter?
Direction and fidelity. The converter answers questions about the data (and necessarily discards comments and anchors, which JSON cannot express). The formatter preserves the document as a document — comments, anchors and aliases included — and answers the housekeeping question: is this file valid, and is it laid out the way the rest of our files are? Use the converter to inspect values; use this to clean up the file itself.
Dev