How to use YAML Formatter
- Paste your YAML.
- Read the formatted output, or the parse error and its location.
- Check that the nesting in the output matches what you intended — that check is the real value.
- Two-space indentation is the convention; tabs are invalid YAML anywhere in the document.
- Comments may not survive reformatting, since most parsers discard them — keep the original.
- Formatting runs in your browser, so CI configuration and secrets are not transmitted.
Indentation errors that parse successfully
The dangerous YAML mistake is not the one that fails — it is the one that parses into the wrong structure. Indent a key two spaces too far and it becomes a child of the line above instead of a sibling, and the file loads cleanly with your setting quietly nested under something else. Reformatting surfaces this: when the output nests a key you expected at the top level, you have found a real bug that no error message would have told you about.
Tabs are forbidden, and the error rarely says so
YAML prohibits tab characters for indentation outright. An editor configured to insert tabs produces a file that fails to parse with a message about an unexpected character, which sends people hunting for a typo. If a YAML file will not load and you cannot see why, check for tabs first — turn on whitespace display, or run the file through a formatter like this one, which normalises everything to spaces.
Quoting, and the values that change type
YAML infers types from unquoted text, which is convenient until it is not. A bare no or off becomes the boolean false, which famously turned Norway’s country code into a false value in real systems. 1.10 becomes the number 1.1, losing a version number’s meaning. A time like 22:30 can be read as a number in some parsers. Anything that must remain a string — version numbers, country codes, IDs, times, anything with a leading zero — should be quoted, and a formatter will not add those quotes for you.
Anchors, aliases and multi-line strings
YAML can define a block once with an anchor (&name) and reuse it with an alias (*name), which is how Docker Compose and CI configurations avoid repeating themselves. Multi-line strings come in two flavours: | keeps the line breaks, > folds them into spaces. Both are preserved through formatting, and both are worth knowing because a shell script embedded in a CI file behaves very differently depending on which you used.
Frequently asked questions
Why is YAML indentation important?
Can it convert between YAML styles?
Does it validate YAML syntax?
Why does my YAML fail with an unexpected-character error?
How many spaces should YAML be indented?
Will formatting change my values?
How do we know nothing is uploaded? Test it yourself on the privacy proof page.