ALL DEVELOPER TOOLS56
YAML Formatter
YAML Formatter & Validator — Free Online Tool
Check a YAML file parses, then re-indent it — with the comments, quoting and anchor names the rewrite costs you spelled out.
About YAML Formatter
This is a YAML formatter that says what it is: the file is read into values with js-yaml and printed again, rather than having its whitespace shuffled around in place. That makes the output guaranteed-valid YAML meaning exactly what the input meant, and it means several things about the text do not come back. Comments are the big one — the parser discards them as it reads and never records where they were, so there is nothing left to write out. Blank lines go the same way, quoting is normalised to whatever the writer thinks each value needs, a merge key is resolved into the keys it merged, and an anchor you named &base comes back as &ref_0, and an anchor on a plain value rather than a mapping loses even that — the value is written out again at each use and the anchor is gone from the file. Where a change can be counted it is counted: how many documents the stream held, which keys were not strings and are about to be quoted or, worse, rendered through your local time zone, and how many nodes will be re-anchored. Validation comes free with the parse. An invalid file reports the parser's own message with the line, the column and the excerpt it prints, and nothing is rewritten until it parses cleanly. Indent, line width and alphabetical key sorting are yours to set, and sorting is off by default because it permanently loses the order the author chose.
Questions
All my comments are gone.
They are, and that is a property of the parser rather than a setting. This formats by reading the file into values and printing them again, and the reader throws comments away without recording where they were — so by the time there is anything to print, there is nothing left to put back. Blank lines go the same way. If your file is heavily commented and you only wanted the indentation fixed, this is the wrong tool: use your editor's YAML formatter, which works on the text rather than the values, and keep this one for checking that the file parses at all.
Why did it put quotes around yes and no?
Because unquoted they are not strings. YAML 1.1 reads y, yes, on, n, no and off as booleans, and plenty of parsers still in use follow that rule — so a value you meant as the word "no" would come back as false. The writer quotes them to keep them strings, which is the safe reading and the reason the Norway problem has its own name. The same applies to a bare 1.0 or a bare date. If you actually wanted a boolean, write true or false, which no parser has ever misread.
Will this tell me why my CI config will not run?
Only if the problem is syntax. It reports the parser's own message, line, column and excerpt for anything that is not well-formed YAML — a tab in the indentation, an unclosed flow sequence, a duplicate key — and those are the majority of YAML failures. It does not know anything about your CI provider's schema, so a perfectly valid file with a misspelled step key or a job that references a stage that does not exist passes here and still fails there. Valid means parses, not means what you intended.
Should I turn on sort keys?
Only when comparing two files. Sorting makes two hand-edited copies of the same config line up so a diff shows real differences rather than ordering, which is genuinely useful once. It is a permanent edit to the output, not a view: the order the author chose is not recoverable afterwards, and most configs read worse sorted — a Compose service with image somewhere after environment tells you less at a glance. It is off by default for that reason, and the warning above the panes says so whenever it is on.
My anchors came back named ref_0 and ref_1.
The structure survived; the names did not. The parser resolves an alias to the node it points at and keeps no record of what the anchor was called, so when the writer notices the same node appearing twice it invents a fresh name. Your data is identical and the file still round-trips — it just reads worse, because &postgres-defaults meant something and &ref_0 does not. The number of nodes this happens to is counted on screen. One case does not survive even that far: an anchor on a plain value rather than on a mapping or a sequence — a version string tagged &tag and pointed at from three services, say. The writer only re-anchors a shared mapping or sequence, so that value is written out again at every use and both &tag and *tag leave the file entirely. The link is gone with them: editing one copy afterwards changes nothing else. That one is not in the re-anchored count, because it is not re-anchored — it is named in the warning above the panes instead. If the names matter more than the reformatting, do not run this over that file.
Is my file uploaded to a server?
No. Transmute processes everything locally in your browser using JavaScript and WebAssembly. Your files never leave your device — there is no server, no upload, no cloud processing.