A beautifier reads your file, then writes a new one
This is the part people get caught out by. Nothing here walks your text fixing indentation line by line. The file is parsed into real values, keys, lists, numbers, booleans, and then printed again from scratch using the profile you picked. The result is guaranteed consistent because it never saw your original spacing. The cost is equally absolute: anything the parser does not keep is gone from the output.
Comments do not survive. A YAML parser reads # lines as whitespace, so they never reach the value the printer writes back. If your file carries explanations your team relies on, keep the original open beside this page and paste your comments back in. The change log counts the comments in your input so the number never surprises you.
What a broken file usually looks like
Four problems account for most of the YAML people arrive here with, and all four come from editing by hand rather than from a generator.
| What is in the file | How it fails | What happens here |
|---|---|---|
| A tab character in the indentation | The spec forbids tabs for indentation, so the parser stops with a message about a character not allowed in this context | Leading tabs are turned into spaces before parsing, and the line numbers are listed in the change log |
| CRLF line endings | Usually parses, then leaves stray carriage returns inside block scalars and quoted values | The browser normalises them to LF the moment text lands in the box, so the rebuilt file is LF only. Nothing to set |
| Indentation drifting by one column | A key silently lands under the wrong parent, so the config loads and behaves wrongly instead of erroring | The rebuild flattens every level onto your chosen indent, which makes the real structure visible |
| A byte order mark from Notepad | Parse error on line one pointing at a key that looks fine | Stripped silently before anything else runs |
The third row is the dangerous one. A tab error stops your deploy immediately and you fix it in a minute. A key sitting one level too deep passes validation, ships, and turns up later as a setting nobody applied. Rebuilding the file is how you see where the parser thinks each key belongs.
Two indentation styles, both correct
Lists are the one place YAML tooling genuinely disagrees, and the disagreement is cosmetic. Both forms below parse to the same three item list.
kubectl styleports:- name: http
port: 80
- name: metrics
port: 9090ports:- name: http
port: 80
- name: metrics
port: 9090Pick whichever matches the files already in your repository. Mixing the two inside one project is what makes diffs noisy, not the choice itself. The profile buttons set this along with the indent width, so choosing Kubernetes gives you flush dashes at two spaces, while Compose, Actions and Ansible give you indented dashes.
Sorting keys is a decision, not a cleanup
Alphabetical sorting is off by default here, which differs from most formatters. Sorted output is excellent for one job: comparing two versions of the same config, where key order noise hides the real change. It is bad for almost everything else. A Compose file reads image, then ports, then volumes because a person put them in the order you need them. Sorting moves build to the top and volumes to the bottom, and the next reviewer sees a rewritten file instead of a two line change.
Turn sorting on when you are about to diff. Leave it off when the file goes back into the repository.
Multi-document files stay multi-document
Kubernetes manifests routinely hold a Deployment, a Service and a ConfigMap in one file separated by ---. Each document is parsed and printed on its own, then joined back with the separators intact, so a bundle goes in and a bundle comes out. The document count in the gauges tells you how many the parser found, which is a quick way to catch a separator someone typed as -- or indented by mistake.
Anchors, aliases and the expansion switch
YAML lets you name a block with &defaults and reuse it with *defaults. Expansion is on by default, so every reference is written out in full. That makes the file longer and repeats the shared block, and it also makes the file readable by tools with partial YAML support, which is most non-Python ecosystems. Turn expansion off when you want the compact form back, and be aware the printer regenerates its own anchor names rather than keeping yours.
Where this tool stops
- Comments are dropped, as described above. This is inherent to any parse and reprint formatter, not a gap in this page.
- Blank lines between sections go too. Visual grouping is not part of the parsed data, so a file with airy spacing comes back dense.
- Custom tags fail. Anything like
!Refor!GetAttfrom CloudFormation, or a language specific tag, is unknown to a plain YAML load and stops with an unknown tag error. Those files need a formatter aware of the dialect. - Number and date literals are re-emitted, not preserved verbatim.
0755and1.50come back as the parser understood them. Quote values where the exact text matters, version strings especially. - Everything runs on the page thread. A few hundred kilobytes is comfortable. Past a megabyte, typing gets sticky and a local formatter is the better call.
- No schema checking. A rebuilt file is valid YAML, which says nothing about whether your Deployment has the fields Kubernetes wants.
Your file never leaves the browser. Parsing, printing, copying and downloading all run in JavaScript after the page loads, so a manifest holding internal hostnames or a token is never sent anywhere. If you only want to know whether a file parses, the YAML validator reports errors without rewriting anything.
