YAML Formatter
Reformat YAML with consistent 2 or 4 space indentation and optional key sorting. Keeps anchors and multi-document files. Runs in your browser, no upload.
Worked examples
- Messy indentation and spacing
Mixed indentation and stray spaces are rewritten to one consistent width, and the trailing comment stays attached to its line.
- Sorted keys with an anchor and a merge key
Sorting reorders keys at every level but keeps the anchor, the alias and the merge key in place, which a convert-to-JSON-and-back formatter would destroy.
- Two documents and a 4-space indent
Multi-document streams keep their separators, and flow style such as [a, b] stays flow style rather than being expanded.
What this does
This tool re-indents and tidies YAML: consistent 2 or 4 space indentation, normalized spacing around keys and comments, one clean layout for sequences, and optional alphabetical key sorting. It runs in your browser and handles files with several documents separated by ---.
How it works
Many online formatters convert YAML to JSON and back, which silently destroys everything JSON cannot hold. This one does not. It parses your text into a YAML document tree, which keeps comments, anchors, aliases, tags and quoting style as part of the tree, and then writes the tree back out with your chosen indent. The parsed values are unchanged, only the layout is rewritten.
What the formatter does:
- Re-indents every level to the width you choose. Mixed indentation, such as 6 spaces in one block and 3 in another, is normalized.
- Normalizes spacing:
key: valuebecomeskey: value, and a trailing comment is separated from the value by one space. - Keeps the structure: anchors (
&base), aliases (*base), merge keys (<<: *base), tags (!!str), and block versus flow style such as[a, b]all survive. - Never wraps long strings. Line folding is turned off so that a long description does not change shape.
- Sorts keys when asked, in every mapping, by plain character-code order, so uppercase comes before lowercase. A merge key
<<always stays first so that explicit keys continue to override merged values. Sequences are never reordered.
Documents are processed independently, and the separator between them is kept.
Comments: kept, but not guaranteed
Preserving comments is not a promise of this tool, but it usually works, because comments live in the document tree. A comment on its own line stays above the line it preceded, and an end-of-line comment stays at the end of its line. Comments in awkward places, such as inside a flow collection or between a key and its value, can move to a neighboring line. When sorting is on, a comment above a key moves together with that key, so a comment at the top of the file can end up in the middle of it. Always check a diff before committing.
Edge cases and limits
- Anchors and sorting can conflict. An alias must come after its anchor in the file. If sorting would put a block that uses
*nameahead of the block that defines&name, the result would be invalid YAML, so the tool stops and tells you to turn off sorting instead of emitting a broken file. - Order can carry meaning. Hand-ordered OpenAPI paths, Docker Compose files grouped by purpose and Kubernetes manifests with metadata first are good reasons not to sort.
- Strict YAML 1.2. Tabs for indentation are an error, and duplicate keys in one mapping are an error with the line and column. Lenient parsers keep the last duplicate silently, which is usually a bug.
- Quoting is retained as written. The tool does not convert
'single'to"double"or remove unnecessary quotes. - Input is limited to 2 MB.
When to use it
- Cleaning up a Kubernetes manifest, Helm values file, CI configuration or Compose file after a merge left the indentation inconsistent.
- Making two config files comparable by sorting their keys before a diff.
- Checking that a hand-edited file is valid YAML: parse errors are reported with their position.
To check YAML without rewriting it, use the YAML Validator, and to move data between formats, the YAML to JSON and JSON to YAML converters are one click away.
Frequently asked questions
- Are comments preserved?
- In most positions, yes: the formatter edits the parsed YAML document rather than converting it to JSON and back, and the parser keeps comments attached to the node they precede or follow. It is not guaranteed, though. Comments in unusual places, such as inside flow collections or between a key and its value, can move or be re-attached to a neighboring line, so compare the output with your input before committing. When sorting is on, a comment above a key travels with that key, so a comment at the very top of the file can end up in the middle of it.
- Does it change my data?
- It should not. Parsed values, anchors, aliases, tags and quoting styles are carried through unchanged; only whitespace, indentation and line layout are rewritten. The one deliberate change is that long plain strings are never wrapped across lines, so a diff shows only the formatting you expect.
- How does sorting keys work?
- Keys in every mapping are sorted alphabetically by their text, using plain character-code order, so uppercase letters come before lowercase. A merge key (<<) always stays first so that explicit keys continue to override merged ones. Sequences are never reordered. Sorting can change the readability of files where order carries meaning, such as Docker Compose, GitHub Actions steps or OpenAPI paths, so leave it off for those.
- Why does it say my YAML is invalid when another tool accepts it?
- This parser follows the YAML 1.2 spec strictly: tabs are not allowed for indentation, and duplicate keys in one mapping are an error. The message includes the line and column where parsing failed. Many lenient parsers accept duplicate keys by silently keeping the last one, which is usually a bug in the file.