YAML Validator & Formatter

Q: Why are my comments missing from the normalised output?

Because normalising works by parsing the YAML into a data structure and writing it back out, and comments are not part of that structure — they exist in the text, not the data. This is true of essentially every YAML normaliser, not just this one, and it is why the normalised pane carries a warning. Treat validation and linting as the primary output here, and use the normalised form for generated or throwaway YAML rather than pasting it back over a config file you have annotated.

Q: Why does YAML reject tab characters?

Because the specification forbids them for indentation, and it is deliberate rather than an oversight. Tabs render at different widths in different editors, so a file indented with a mix of tabs and spaces would nest differently depending on who opened it — catastrophic for a format where indentation defines structure. The error a parser gives is often unhelpfully vague, which is why this tool names the line. Configure your editor to insert spaces for .yml and .yaml files and the problem disappears permanently.

Q: What is the Norway problem?

YAML's older specification treats a set of bare words as booleans, so the country code NO becomes false, and ON, OFF, YES and Y behave similarly. A list of country codes containing Norway therefore parses with a boolean sitting in the middle of it. The same class of problem turns a version number like 1.20 into the number 1.2 and a leading-zero code into an octal. The fix is always quoting: any value whose exact text matters should be in quotes, and this tool flags the values in your document that are at risk.

Q: Are duplicate keys an error?

The specification says a mapping must not have duplicate keys, but most parsers accept them anyway and silently keep the last one. That makes it one of the more dangerous YAML mistakes: a configuration file with the same key twice loads without complaint and applies a value you may not have noticed. It happens most often after a merge, or when a long file has drifted. This tool reports every duplicate it finds rather than quietly resolving it the way a parser would.

Q: Does it support anchors, aliases and multiple documents?

Multiple documents separated by --- are detected and reported, though only the first is normalised. Anchors and aliases, the & and * syntax for reusing a block, are recognised and flagged as present but not expanded — resolving them changes the document's meaning in ways that are better done deliberately than automatically. If your file uses either heavily, treat this tool as a linter for the parts it understands rather than a complete implementation of the specification.

Q: Should I use YAML or JSON for configuration?

YAML is far more pleasant to read and write by hand, supports comments, and is the reason it dominates infrastructure tooling. The cost is the ambiguity described above — implicit typing, significant whitespace, and a specification large enough that implementations genuinely disagree at the edges. JSON has none of that expressiveness and none of those traps. A reasonable rule is YAML for files humans edit and JSON for anything machines generate or exchange.

Validate YAML, catch tabs, duplicate keys and the implicit-typing traps, and see a normalised version with consistent indentation.

YAML

Indent width

Normalised (comments not preserved)

Validation and normalisation run entirely in your browser. Note that comments are not preserved in the normalised output — they are not part of the parsed data.

What It Does

This checks YAML for the mistakes that YAML specifically invites, then shows you a normalised version with consistent indentation. The validation is the more valuable half. YAML's flexibility is also its hazard: indentation carries meaning so a tab silently breaks the structure, duplicate keys are accepted by most parsers which quietly keep the last one, and a set of bare words are implicitly converted to booleans and numbers in ways that surprise almost everyone the first time. This tool reports each of those against your actual document rather than describing them in the abstract. The normalised output re-indents everything consistently and quotes the values that would otherwise be misread — with one honest caveat, stated up front: comments are not preserved, because they are not part of the parsed data.

When to Use It

A CI pipeline is rejecting your workflow file with an unhelpful parse error and you need to know which line is actually at fault.
A configuration file behaves differently from what it appears to say and you suspect a duplicate key is overriding something.
A list of country or region codes is misbehaving and you want to see which entries YAML is silently turning into booleans.
You inherited a file with inconsistent indentation and want it normalised before committing a change to it.
You are checking machine-generated YAML before it goes into a deployment.

Worked Examples

countries:
  - NO
  - SE
  - DK

The Norway problem in three lines. NO parses as the boolean false rather than the string "NO", so the list is not what it appears to be. The tool flags it and the normalised output quotes it.

server:
  port: 8080
  host: localhost
server:
  port: 9090

A duplicate key, the kind that survives a careless merge. Most parsers accept this silently and keep 9090, so the first block is simply ignored — which is exactly the sort of thing that costs an afternoon.

version: 1.20
enabled: yes
code: 0755

Three implicit-typing traps at once. The version becomes the number 1.2 and loses its trailing zero, yes becomes a boolean, and the leading zero makes the code an octal number.

Features

Validation with the failing line identified

Tab indentation detected and located

Duplicate key detection across the document

Implicit typing traps flagged including the Norway problem

Multiple document markers detected

Anchors and aliases reported when present

Normalised output with consistent indentation

Configurable indent width

Risky values quoted automatically in the output

Runs entirely in your browser

How to Use

1. Paste your YAML into the input box. 2. The verdict appears immediately, with the line number if it fails to parse. 3. Read the findings for tabs, duplicate keys and implicit typing risks. 4. Adjust the indent width if you want the normalised output to match your house style. 5. Copy the normalised version, remembering that comments are not carried over.

Common Mistakes

Indenting with tabs. YAML forbids them outright, and the resulting parse error rarely points at the real problem — set your editor to use spaces for YAML files.
Leaving version numbers and codes unquoted. 1.20 becomes 1.2, 0755 becomes an octal, and a leading-zero identifier loses its zero, all without any warning.
Assuming duplicate keys will be rejected. Most parsers keep the last one and say nothing, so a stray repeated key silently overrides configuration above it.
Pasting normalised output back over an annotated config file. Comments are not part of the parsed data, so they do not survive the round trip.
Trusting that two YAML parsers agree. The specification is large enough that implementations differ at the edges, so validating here is a good check but not a guarantee for every consumer.

Frequently Asked Questions

Why are my comments missing from the normalised output?

Why does YAML reject tab characters?

What is the Norway problem?

Are duplicate keys an error?

Does it support anchors, aliases and multiple documents?

Should I use YAML or JSON for configuration?