YAML Formatter

Validate and normalize YAML — multi-document streams supported.

Indent

Sort keys

YAML Input

Formatted

Normalizing YAML

YAML is whitespace-sensitive, so inconsistent indentation is a common source of bugs. This formatter parses your YAML (validating it and reporting any syntax errors), then re-serializes it with consistent indentation and normalized structure — flow collections become block style. It handles multi-document streams (separated by ---), preserves key order by default, and offers an optional sort-keys pass. All parsing happens locally in your browser.

Built and maintained by Meet Shah · Last updated 24 July 2026

What this tool is used for

Normalising indentation in a CI or Kubernetes manifest that someone edited with a different editor.
Finding the line where a pipeline config stopped parsing, when the runner only says the file is invalid.
Checking whether a value you meant as a string is being read as a boolean or a number.
Making a hand-written manifest consistent before committing it, so the diff shows intent rather than whitespace.
Confirming a multi-document file is split the way you expect before feeding it to a tool.

How it works in practice

A worked example

A manifest that used a shared block for its defaults comes back from the formatter noticeably longer, and you want to know exactly what it did.

Input

# cluster config
name: web
enabled: no
version: 1.0
port: "8080"
defaults: &d
  retries: 3
  timeout: 5
prod:
  <<: *d
  retries: 5
---
name: worker
enabled: yes

Output

name: web
enabled: 'no'
version: 1
port: '8080'
defaults:
  retries: 3
  timeout: 5
prod:
  retries: 5
  timeout: 5
---
name: worker
enabled: 'yes'

Four changes, and only the quoting is cosmetic. The comment has gone, because the file was parsed into data and written back out and a comment is not data. The anchor and the merge key have gone too — the second block now carries its inherited values inline, which is semantically identical, textually larger, and no longer a single place to edit them. The bare word became quoted, which is the formatter making an ambiguity explicit rather than introducing one. And the version dropped to a plain integer, because unquoted it was never a string.

The edge case that catches people

It will also quietly wreck a Helm chart. A value beginning with a brace is not templating as far as a YAML parser is concerned — it opens a flow mapping, so the line parses, yields a nested map whose key is a stringified object, and gets written back out in that state with no error reported anywhere. GitHub Actions escapes the same trap by accident, because its expressions begin with a dollar sign and are therefore ordinary scalars. Quote the value and the templating survives the round trip; leave it bare and it does not.

When not to use this tool

So: not on a template, and not on a file whose comments are its documentation. Anything processed by Helm or Kustomize before a parser ever sees it belongs to that tool's own linter, not to something that has to interpret the file first in order to reformat it. The same applies to a hand-maintained manifest where an anchor exists specifically so one value lives in one place. The trip through here is one-way and there is no option to preserve either, so keep a copy of the original if it is the file you are going to keep editing.

Frequently Asked Questions

Why does YAML use indentation instead of braces?: To be readable as configuration. The cost is that whitespace is load-bearing — and TABS ARE FORBIDDEN entirely by the spec, which is the single most common YAML error since most editors insert them invisibly.
What is the Norway problem?: In YAML 1.1, the unquoted value NO parses as the boolean false — so a country list containing Norway's code silently becomes false. ON, OFF, YES and Y behave similarly. YAML 1.2 fixed it, but many parsers still implement 1.1.
Why did my version number become a different value?: Because unquoted 1.10 is a float and drops the trailing zero to 1.1, and 1.2.3 is a string only because it has two dots. Version numbers and anything with leading zeros must be quoted.
What is the difference between | and > in block scalars?: | is literal and preserves newlines; > is folded and joins lines into one, keeping only blank-line breaks. Adding a - (|-) strips the trailing newline. Choosing the wrong one silently reshapes multi-line strings.
Is YAML a superset of JSON?: YAML 1.2 is, so any valid JSON is valid YAML and can be pasted directly. The reverse is not true, since YAML's anchors, comments and multiple documents per file have no JSON equivalent.
What are anchors and aliases?: `&name` marks a node and `*name` reuses it, letting you define a block once and reference it repeatedly. Merge keys extend that to maps. They are why a YAML file can be far smaller than the structure it produces — and harder to read.
What is a document separator for?: `---` starts a new document in the same file, and `...` ends one. It is how Kubernetes manifests pack several resources into one file, and it means a YAML parser can return a stream of documents rather than a single value.

Common errors and gotchas

Using tabs for indentation. YAML forbids them outright, and most editors show them identically to spaces.
Leaving an unquoted `yes`, `no`, `on` or `off` and getting a boolean where you wanted the word.
Writing a version like `1.10` unquoted, which becomes the number 1.1 and silently drops the zero.
Misaligning a nested list by one space, which reparents the item under a different key without any error.
Assuming a colon inside an unquoted value is safe. `key: a: b` is a parse error, not a string.