Standardize YAML Formatting Across Your Team

Why a consistent YAML style matters, the tab vs space rule, and how to normalize files before a GitHub commit.

Normalize any file with the YAML Formatter → and check it with the YAML Validator →

The one rule that prevents most YAML fights

YAML forbids tabs for indentation. A file that mixes spaces and tabs — or uses tabs at all — parses differently per editor and breaks on CI. The convention is 2 spaces per level. Agree on it once and every diff stays clean.

config:
  debug: true
  level: 3

Use the formatter as a pre-commit gate

Before a git push to GitHub, paste the file into the YAML Formatter. It re-indents with consistent 2-space indentation and rewrites inconsistent structures, so a teammate's 4-space file becomes uniform. Then run the YAML Validator to be sure nothing regressed.

Formatter vs minifier

The Formatter keeps readable indentation; the Minifier collapses it for size. Use the formatter for source in git, the minifier for generated artifacts. Both preserve your data exactly — see the indentation guide for the full rules, and the errors guide if formatting surfaces a hidden parse error.

FAQ

How many spaces should YAML indentation use?

The common convention is 2 spaces per level. What matters most is consistency and never using tabs, since YAML forbids tab indentation.

Can I use tabs in YAML?

No. The YAML spec forbids tabs for indentation; a single tab breaks parsing. Use spaces and run a formatter to normalize files.

How do I keep a team's YAML consistent?

Format every file with a YAML formatter (2-space indentation) before committing to GitHub, then validate it so inconsistent or broken files never reach the repo.

Keep reading