YAML Formatter

Reformats YAML with consistent indentation and structure, and reports a parse error with its location when the document is invalid. Since YAML's indentation *is* its syntax, formatting it is closer to validation than to cosmetics.

Live demo · real result from this tool
Indent
0 never wraps.

Formatted YAML

name: deploy'on':  push:    branches:      - mainjobs:  build:    runs-on: ubuntu-latest    steps:      - uses: actions/checkout@v4      - run: npm ci      - run: npm test 

Processed on your device — nothing is uploaded.

How to use YAML Formatter

  1. Paste your YAML.
  2. Read the formatted output, or the parse error and its location.
  3. Check that the nesting in the output matches what you intended — that check is the real value.
  4. Two-space indentation is the convention; tabs are invalid YAML anywhere in the document.
  5. Comments may not survive reformatting, since most parsers discard them — keep the original.
  6. 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?
YAML uses indentation to define structure, like Python. Incorrect indentation changes meaning or makes YAML invalid. Proper formatting ensures correct parsing.
Can it convert between YAML styles?
The formatter uses standard YAML style with 2-space indentation. It normalizes different styles to consistent formatting.
Does it validate YAML syntax?
Yes, the formatter attempts to parse YAML and will show errors if the syntax is invalid, helping you debug configuration files.
Why does my YAML fail with an unexpected-character error?
Check for tab characters. YAML forbids tabs for indentation and the resulting message rarely names them. An editor set to insert tabs will produce this every time; switch the file to spaces.
How many spaces should YAML be indented?
Two per level, by near-universal convention. YAML permits any consistent amount, but every widely used configuration format — Kubernetes, Docker Compose, GitHub Actions — uses two, and consistency within a file is mandatory.
Will formatting change my values?
It should not change data, but it can expose that a value was never what you thought: an unquoted no was already the boolean false before formatting. If a value looks different afterwards, quote it in the source — the formatter revealed the problem rather than creating it.

Written by the ToolsRift team · Last updated

Pages are drafted with AI assistance and checked by automated tests. How we write and check pages.

Was this tool useful?

Report a problem

Start typing to search every tool.

↑ ↓ to moveEnter to openEsc to close