YAML Formatter & Validator

Most free YAML formatters have a nasty habit. You paste in a config file, click format, and every comment you wrote is gone. The tool ran your YAML through a plain data structure to tidy it, and a plain data structure has nowhere to keep the note that explained why that timeout is set to 30. This one keeps your comments while it validates the YAML, fixes the indentation, and writes it back out with the comments still sitting on the right lines, entirely in your browser with nothing uploaded.

It also reads multi-document files, the kind Kubernetes bundles with --- separators, instead of stopping at the first document the way a lot of formatters do. And it gives you actual control over the output: 2 or 4 space indent, sorted keys, a line width, and block or flow layout. No account, no upload, no daily cap. Your file can hold database passwords and API tokens and it never leaves the tab.

1. Paste your YAML into the box, drop a .yaml or .yml file straight onto it, or click Open file. A file copied from your file manager pastes in too.
2. The cleaned, validated result appears on the right as you type. There is no format button to go looking for.
3. Set the output the way you want it with the controls: indent width, sort keys, line width, and block or flow style. More on each of those below.
4. If something is broken, you get the line, the column, and a caret pointing at the exact character, not a vague complaint about the file being wrong somewhere.
5. Copy the result, or download it as a .yaml file. The Share button copies a link that remembers your exact settings, so you can pin the same formatting for next time.

This is where a good formatter separates itself from a text box that just re-indents.

Indent. Two or four spaces. Worth knowing: both options are spaces, because YAML flat out forbids tab characters for indentation. There is no tab choice here on purpose, it would produce a file the next parser rejects. Two spaces is the convention across Kubernetes and Docker land, so that is the default.

Sort keys A to Z. This alphabetizes the keys in every mapping, and it walks all the way down into nested maps. The reason you want it is diffs. Two people edit the same config, the keys end up in different orders, and code review turns into noise. Sort both and the real change stands out. It sorts mapping keys only, never list items, because a list's order usually carries meaning, the steps in a CI job or the arguments to a command should not get shuffled. When a key moves, its comment moves with it.

Line width. Long string values fold at 80 or 120 columns so the file stays readable. Set it to No wrap when you have a long URL or token that keeps breaking across lines in an ugly way, and you would rather it stay on one line no matter how far it runs.

Block or flow. Block is the normal, readable, multi-line layout you expect from YAML. Flow collapses collections into the compact inline form, like {name: web, ports: [80, 443]}. Flow is handy for a tiny snippet you want to drop into a chat message. For a real config file you almost always want block.

The comment thing is the one that actually costs you. A comment in a config file is documentation, the reason the person after you (or you in six months) knows why a value is what it is. A formatter that strips every comment on each run is doing real damage silently, so you do not notice until the knowledge is gone. This tool parses at the document level, the part most tools skip, and that is what lets the comments survive the round trip.

Multi-document files are the other common failure. A single YAML file can hold several documents separated by a line with just ---, and Kubernetes leans on that constantly to ship a Deployment and a Service and a ConfigMap together. A formatter that only understands one document per file will either throw an error on the second --- or quietly keep the first document and drop the rest, and both of those outcomes are bad. This one reads the whole stream, formats each document, and puts the separators back where they belong.

Two honest limits come with those features, both about comments, and both covered in the FAQ below. Neither is a bug, it is just what flow style and sorting do.

Some of the worst YAML bugs are perfectly valid syntax. The file parses, a plain validator says fine, and your value is quietly the wrong type.

The Norway problem is the famous one. Under older YAML rules the unquoted word NO parses as the boolean false, so a list of country codes with NO for Norway silently loses that entry. The words yes, no, on, off, true, and false all go boolean when they are not quoted, so quote them whenever you mean the literal text.

Numbers do it too. Write version: 1.10 unquoted and it becomes 1.1, the trailing zero just gone. A leading-zero code like 007, a long account ID, or a bare 12:30 you meant as text all get read as something else unless you quote them. The rule that avoids nearly all of this is simple. If a value could pass for a number, date, time, or boolean and you want plain text, wrap it in quotes. The formatter lays out what you give it, it does not rewrite your quoting, so this part stays on you.