YAML Formatter & Validator

YAML formatter: fix the indentation, and see what your values really are

Paste YAML on the left; the reformatted document appears on the right as you type, with a status bar above it that is green when the document parses and amber when it does not. Nothing is uploaded — the parser and the emitter are JavaScript running in your browser, which matters more for YAML than for most formats, because YAML files are usually pipeline configs and Kubernetes manifests with hostnames, bucket names, and account IDs in them.

The tool does two things at once. It validates: if the document cannot be parsed you get the reason and the exact line and column, and no output. If it parses, it re-emits the document from the parsed data with consistent indentation (2 or 4 spaces), optional alphabetical key sorting, block style throughout, and no line wrapping. Multi-document streams separated by --- are handled as a unit and rejoined with --- between them.

Because the output is regenerated from the parsed value rather than patched in place, the round trip is honest about what your file actually means — and that is where most of YAML's surprises live.

Read this first: the formatter drops your comments

YAML comments are not part of the data model. The parser produces the mapping, the emitter writes the mapping, and the # lines are gone. That is standard behaviour for load-and-dump YAML tooling, and it is unavoidable here, but it makes the tool wrong for one job: reformatting a heavily annotated config in place. Use it to inspect such a file — check that it parses, see the real types, see the canonical shape — and keep your annotated original. For files that are generated anyway, or scratch YAML you are assembling, formatting in place is fine.

A file containing nothing but comments parses to an empty document and comes out as the single word null. That is not a bug; it is what a comment-only YAML document contains.

Whitespace is the syntax

Every YAML error people actually hit traces back to one design decision: indentation carries structure, the way braces do in JSON. Three rules follow, and the parser enforces all three.

Tabs are forbidden in indentation. Not discouraged — illegal. The spec excludes the tab character from indentation entirely, because a tab has no defined width and the structure would depend on your editor's settings. Indent with a tab and the status bar reads ⚠ tab characters must not be used in indentation (line 2, column 1). This is the number one YAML error in the wild and the number one reason to set your editor to expand tabs for .yaml and .yml. A tab inside a value, after the colon, is fine — it becomes part of the string.

Siblings must line up exactly. Indentation is relative, not fixed: any consistent number of spaces defines a level, and two spaces is only a convention. But once a level is established, every key at that level must start at that same column. Nudge one key a single space and you get ⚠ bad indentation of a mapping entry with the line and column of the offender.

Sequence items may be flush with their parent key. This is the one that makes YAML look inconsistent between projects. Both of these are valid and mean the same thing:

The formatter always indents sequence items under their key, so mixed styles in one file get normalised. Nested maps inside a sequence keep their alignment: the - and the first key share a line, and the remaining keys line up under that first key.

Block style, flow style, and multi-line scalars

YAML has a JSON-like flow style — {beta: true, legacy: false}, [web, edge, prod] — alongside the indentation-based block style. Both are legal anywhere a collection is legal, and flow style is genuinely useful for short lists inside long files. This formatter expands all of it to block style; that is the point of a canonical re-emit, but if you deliberately keep short lists on one line, this tool will undo that choice.

For long strings YAML offers two block scalar indicators, and the difference between them is the single most useful thing to know about the format:

• | literal — newlines inside the block are preserved. Use it for scripts, certificates, SQL, and anything where line breaks are part of the value.
• > folded — newlines are folded into single spaces, so you can wrap a long sentence across several lines in the file and get one line in the value. A blank line inside a folded block becomes a real newline.
• Either can take a chomping indicator: |- strips the trailing newline, |+ keeps all trailing newlines, and plain | keeps exactly one.

Note what happens on the round trip. The folding is applied at parse time, so a > block arrives in the data model as one already-joined line — and comes back out as a | literal containing that joined line. The value is identical; the notation is not. If you rely on > for readability in a source-controlled file, keep your original.

Anchors, aliases and merge keys are expanded, not preserved

YAML can define a node once with an anchor &name, refer to it elsewhere with an alias *name, and merge one mapping into another with <<: *name. The parser resolves all of it, and the emitter is configured to write out plain values rather than re-create the aliases. So this:

defaults: &d /   a: 1 /   b: 2 / svc1: /   <<: *d /   b: 3 / svc2: *d

… comes back with svc1 written out in full as a: 1, b: 3 — the merge applied, the local override winning — and svc2 written out as its own copy of a: 1, b: 2. That is exactly what you want when you are debugging ("what does this manifest actually say after the merges?") and exactly what you do not want if you were hoping to tidy a DRY config and keep it DRY. Expanded output is also how you catch a merge that silently loses an override.

Implicit typing: the values that change under you

YAML infers a type from the shape of an unquoted scalar. Most of the time that is a convenience. Sometimes it quietly rewrites your data, and the formatter makes it visible because the re-emitted value is the parsed value. Every row below is this tool's actual behaviour:

The version-number one is the classic production incident: 1.10 is a float, floats have no trailing zeros, and the tag you meant to pin becomes 1.1. Same family: an identifier with a leading zero loses it, a decimal like 3.0 loses its point, and a bare date becomes a timestamp with a timezone attached. The fix in every case is quoting. ver: "1.10", zip: "01234", when: "2026-08-28" all survive untouched, and quoted digits are why the formatter leaves them alone.

The Norway problem, and which YAML version you are talking to

The famous version of this trap is a country list in which NO — Norway — is read as the boolean false. It comes from YAML 1.1, whose boolean set includes yes, no, on, off, y and n in several capitalisations. YAML 1.2 narrowed booleans to true and false only.

This formatter follows the 1.2 core schema. Confirmed against the tool: yes, no, on, off and NO all stay strings here, and only true/false become booleans. But the parser reading your file in production may not agree — several widely deployed parsers are still 1.1, which is why this bug is still being reported decades later. The formatter hedges for you: on output it quotes those words, so no comes back as 'no' and a key named n comes back as 'n', and the quoted form is unambiguous under both versions. If your YAML is consumed by a 1.1 parser, treat that quoting as the correct shape and keep it.

The practical rule needs no version knowledge: quote every value that is meant to be text, particularly two-letter codes, version numbers, ports written as strings, IDs with leading zeros, and anything a human might read as a yes/no answer.

Errors you will see, and what they mean

Every message carries a 1-based line and column, so you can jump straight to the character. Two habits catch most of the rest before they happen: put a space after every colon (key:value is one scalar, not a mapping), and quote any value containing : , or starting with *, &, #, @, %, or -.

Options, and the small print

• Indent — 2 or 4 spaces, applied to mappings and sequences alike. Tabs are not offered, because they are not legal.
• Sort keys — sorts every mapping in the document alphabetically, at every depth. Useful for diffing two configs that differ only in key order; destructive to a file whose ordering is meant to be read top-to-bottom.
• No line wrapping — long scalars stay on one line rather than being folded at a column limit, so a URL or a base64 blob is never broken across lines.
• Copy — puts the formatted document on your clipboard.

What the tool does not do: it has no minify mode (YAML has nothing meaningful to minify), it does not convert to or from JSON, and it does not check your document against a schema — a Kubernetes manifest with a misspelled field is still perfectly valid YAML, and this tool will tell you so. For structural validation against a schema you need a schema validator; for a JSON round trip, the data format converter is the sibling tool for that job.