YAML Fixer — Repair Broken YAML
Paste YAML that will not load and get a document back that parses
Input
Repaired YAML
What the YAML Fixer does
YAML errors are unusually hostile because the thing the parser complains about is almost never where the mistake is. could not find expected ':' at line 47 routinely means somebody indented line 12 with a tab. The parser kept reading, built a structure nobody intended, and only fell over thirty-five lines later when that structure stopped making sense. So you stare at a line that is perfectly correct.
This page takes the document your parser rejected and hands back one that loads. Tab indentation becomes spaces, a key:value missing its space gets one, a value containing a colon or starting with *, & or % gets quoted, and inconsistent nesting is squared up. The result is a document that satisfies the YAML 1.2 specification.
One thing worth being upfront about: indentation in YAML is meaning, not formatting. Moving a line by two spaces does not tidy the document, it moves a key into or out of a mapping and changes what your application reads. Where the original indentation is genuinely ambiguous, a repair has to guess — so read the right-hand panel against what you expected, rather than copying it out on trust.
If you would rather see the error than have it corrected, the YAML Validator reports the line and column and leaves your bytes exactly as they are. And if what you actually want is to read the data rather than repair it, YAML to Table is usually faster than squinting at nesting.
How to repair a broken YAML document
- Paste the document that fails – Drop the YAML into the left panel. Upload reads a .yml, .yaml or .txt file straight off disk without checking it first, which matters here — the whole point is that the file does not parse yet. Sample loads a deliberately broken network config you can experiment with.
- Press Fix YAML – The button sits at the top of the input panel and stays disabled while a repair is running, so a slow response cannot turn into two requests against the same document.
- Check the indentation first – This is the part that matters most and the part people skip. Confirm every key sits at the depth you meant. A key that moved one level has not been reformatted — it now belongs to a different parent, and your application will read a different value.
- Look at what got quoted – Quoting is how most YAML repairs work, and it changes types. A value that was being read as a number or a boolean becomes a string, which is usually exactly what you wanted — but check it is what your schema expects.
- Verify long identifiers survived – ICCIDs, IMSIs and account numbers run to 18 or 19 digits. The repaired text goes into the editor as text and is never routed through a numeric type, so every digit you paste in is a digit you get back.
- Copy or download – Copy puts the result on your clipboard and Download saves it as fixed.yaml. There is no Minify here on purpose — YAML has no meaningful minified form, because the whitespace is the structure.
Pro tip: if the repair moves keys to a nesting depth you did not expect, the original almost certainly mixed tabs and spaces. Your editor renders a tab as however many columns it is configured for, so two lines that look perfectly aligned on your screen are at different depths as far as the parser is concerned. Turn on "render whitespace" and look at the original before trusting either version.
Example: a config that stops a deploy
Three problems in five lines, and a parser reports only the first thing that confuses it. The port line is indented with a tab, the description contains an unquoted colon, and the version lost its quotes and is now a number.
service: sim-provisioning version: 1.20 network: →port: 8080 note: Outage: cell 4021 offline
service: sim-provisioning version: "1.20" network: port: 8080 note: "Outage: cell 4021 offline"
Eight ways YAML stops parsing
These are in rough order of how often they turn up. Every one of them produces a message that points somewhere other than the mistake, which is why YAML has the reputation it does.
A tab used for indentation
service: →port: 8080
Tabs are flatly illegal as YAML indentation — not discouraged, illegal. The specification excludes them so that a document means the same thing regardless of anyone's tab width. The message is usually found character '\t' that cannot start any token, which at least names the cause, but plenty of files mix tabs and spaces and only break much further down. Configure your editor to insert spaces in .yaml files and this whole category disappears.
No space after the colon
msisdn:447700900142 imsi: 234150999912345
key: value needs the space. Without it, msisdn:447700900142 is not a key and a value — it is a single scalar string with a colon in the middle. That is perfectly legal YAML, so you get no error at all; you get a list item or a value that is not the mapping you wanted, and the failure surfaces later as a missing config key. This is the one that costs the most time, because nothing is reported.
An unquoted value containing a colon
note: Outage: cell 4021 offline window: 09:00 to 17:00
A colon followed by a space is what separates a key from a value, so YAML sees a second one and reports mapping values are not allowed in this context. Wrap the value in quotes and it is fine. Note the space matters: https://example.com is usually accepted because the colon is followed by a slash, which is why URLs often work while a sentence with a colon does not.
Indentation that does not line up
cells: - id: 4021 rsrp: -97 tac: 17
Every key in the same mapping must start at the same column. tac above is three spaces in where its siblings are four, and the parser reports bad indentation of a mapping entry — pointing at tac, which for once is the actual culprit. YAML does not care whether you indent by two spaces or four, only that you are consistent within a block. Mixing widths between blocks is legal but makes this mistake far easier to make.
A version number that lost its quotes
version: 1.20 image: "registry/agent:1.20"
1.20 is not a string, it is the number 1.2 — the trailing zero is gone the moment it is parsed, and you deploy the wrong version. Worse, 1.20.1 has two dots so it stays a string, meaning the bug appears and disappears depending on the release. Always quote version numbers. The same trap catches anything zero-padded: an account code of 00417 becomes 417.
Implicit typing, and the Norway problem
countries: [NO, SE, DK] enabled: yes
Under YAML 1.1, NO, yes, on and off are booleans — so Norway's country code becomes false. YAML 1.2 narrowed booleans to true and false only, so the same file means different things depending on what reads it: PyYAML still follows 1.1 and returns False, while js-yaml follows 1.2 and returns the string "NO". That parser split is the real bug and it is nastier than the folklore version — a config that behaves in Node and misbehaves in Python. Quote the value and it is unambiguous everywhere. This write-up on implicit typing is the best argument for quoting by default.
A value starting with a special character
password: *Str0ng! ref: &prod-cluster
* and & are the alias and anchor markers, so *Str0ng! is read as a reference to an anchor named Str0ng! that does not exist, and you get unidentified alias. The same applies to a leading @, %, `, {, [, ! or #. Quoting fixes all of them. Generated passwords hit this constantly, which is a good reason to always quote secrets in a config file.
The same key twice
apn: internet plan: Unlimited 5G apn: wap
Duplicate keys in the same mapping are invalid, but almost every parser accepts them anyway and silently keeps the last one — so apn is wap and the earlier line is discarded without a word. It happens whenever two config files are merged or a block is copied and half-edited. Some tools warn with duplicated mapping key; most say nothing, which is why a value you can plainly see in the file is not the value your application gets.
If none of these match, the next thing to check is the invisible characters. A document copied out of a wiki, a chat client or a PDF frequently arrives with non-breaking spaces instead of ordinary ones, or with curly quotes that YAML does not recognise as quotes at all. Both look completely normal in an editor. The yaml tag on Stack Overflow is a good place to match an unfamiliar message against the parser that produced it, since the wording differs sharply between PyYAML, js-yaml, SnakeYAML and Go's yaml.v3 for the identical broken byte.
When you will reach for this
A CI pipeline that will not start
GitHub Actions workflows, GitLab CI and CircleCI configs all fail before running a single step, and the error in the web UI is often just "invalid workflow file" with a line number that points at the end of the document. Repair it here, then read the result against what you intended — particularly the nesting under jobs and steps, where one level of indentation is the difference between a step and a whole new job.
Kubernetes manifests and Helm output
A Kubernetes manifest that fails kubectl apply with a parse error is usually a templating accident: a Helm value landed unquoted, or an if block left the indentation one level out. Multi-document files add their own trap, since a malformed --- separator merges two resources into one.
Docker Compose and application config
docker-compose.yml, Spring's application.yml, Ansible playbooks — all of them fail hard and early. Watch for ports and versions in particular: ports: - 8080:8080 and an unquoted image tag are the two that most often parse successfully into something you did not mean.
YAML pasted out of a ticket or a chat
By the time a config reaches a bug report it has usually been through a client that reflowed the lines, converted straight quotes to curly ones and replaced some spaces with non-breaking ones. Getting it back to something parseable is the first step; after that, YAML to JSON often makes the structure far easier to check than the original.
Config full of long identifiers
Telecom and banking config is dense with 18- and 19-digit numbers: ICCIDs, IMSIs, IBANs. Plenty of tools route every numeric-looking value through a floating point type and quietly turn 8901240544102066246 into 8901240544102066000. This page treats the repaired document as text from end to end, so nothing is re-typed behind your back.
Frequently asked questions
Why does the error point at the wrong line?
Because YAML is whitespace-structured, a mistake changes the shape of the document rather than breaking it immediately. An extra level of indentation on line 12 makes the parser build a nested mapping instead of a flat one; it carries on happily until something later is impossible inside that shape, and reports there. The practical rule is to look above the reported line, not at it — and specifically at the last place the indentation changed.
Will it change my values as well as my syntax?
Mostly it adds quotes, which changes a value's type rather than its text: 1.20 becomes "1.20", so the characters survive where a number would have lost the trailing zero. That is normally exactly what you want. Where it matters is a schema expecting an integer — if your application requires a number and now receives a string, unquote that one line deliberately.
Does it preserve my comments?
Comments are the main reason people choose YAML over JSON, so this is worth being clear about: a repair may not preserve all of them. Comments carry no structural meaning, and a document rebuilt to fix its indentation cannot always place them back where they were. Keep the original — it is the one thing here you cannot regenerate. The YAML Formatter carries the same warning for the same reason.
What is the difference between this and the validator?
The validator tells you what is wrong and where, and hands your document straight back untouched. This page changes the document so that it loads. Use the validator when you want to understand and fix the problem yourself — which is the better habit for a config file you own — and this one when you have been handed something broken and need it working now.
Is JSON valid YAML?
Yes. YAML 1.2 is a strict superset of JSON, so any valid JSON document is already valid YAML and you can paste one straight into a YAML parser. It does not work in reverse: YAML's indentation-based syntax, comments, anchors and multi-document files have no JSON equivalent. If you want the conversion rather than the trivia, YAML to JSON and JSON to YAML both handle it.
What happens to anchors and aliases?
Anchors (&name) and aliases (*name) are a real risk area, because a repair that expands them produces a document that behaves identically but is much longer, with the shared block duplicated everywhere it was referenced. Check for that specifically if your file uses them — it is not an error, but it is not what you handed over either.
Is there a size limit?
Yes, and it is deliberately modest. Repairing a very large document is slow and the result is much harder to review than it is worth. With a big file it is almost always quicker to let the validator give you a line number, and repair that section on its own.
How do I stop this happening again?
Three habits remove most of it. Configure your editor to insert spaces rather than tabs for .yaml files. Quote anything that is not plainly a number — versions, country codes, secrets, anything zero-padded. And run a linter such as yamllint in CI so a malformed file is caught on the branch rather than during a deploy.