Why does this tool need a seed?

So the corruption is reproducible. Errors are chosen using a small deterministic pseudo-random number generator (mulberry32) rather than `Math.random()`, meaning the same input, seed, and error count always produce byte-for-byte identical corrupted output, useful for a stable test fixture you can commit and rerun.

What kinds of errors does it introduce?

Three kinds, chosen pseudo-randomly per line: deleting the colon from a `key: value` pair (or a trailing mapping colon), inserting a stray leading space that breaks a line's indentation alignment with its siblings, and removing one quote character to leave an unterminated quoted string.

What happens if I ask for more errors than the document has lines?

The error count is capped at the number of non-blank lines in the document, since each targeted line receives at most one mutation. Asking for 50 errors in a 5-line document introduces at most 5.

Is the corrupted output guaranteed to fail parsing?

Not with absolute certainty for every mutation, some lines (like a scalar without a colon nearby) may have no applicable mutation and are skipped, and an inserted stray space doesn't always land somewhere that breaks parsing. In practice, requesting a handful of errors on a multi-line document reliably produces YAML that fails to parse, but for a guarantee, verify the output with the YAML Validator afterward.

Does this tool send my YAML anywhere?

No, corruption happens entirely client-side, no upload, no external service. The seeded PRNG runs locally in your browser.

YAML Error Injector - Generate Broken YAML for Testing

Overview

Introduction

Testing a YAML parser, linter, or error-handling code path properly means feeding it broken input, not just valid documents, but generating realistic, varied broken YAML by hand is tedious and easy to make too broken (or not broken at all) by accident. This tool automates that: it takes valid YAML and deliberately introduces a chosen number of syntax errors.

Because the corruption is seeded rather than random, the exact same broken output can be regenerated on demand, useful for committing a stable fixture to a test suite rather than a document that changes every time you run the generator.

What Is YAML Error Injector?

A YAML error injector that takes a valid document and a small set of options (how many errors, and a seed) and mutates a chosen number of lines using one of three corruption strategies: deleting a colon, breaking indentation, or unbalancing a quote.

Which lines get mutated and which strategy applies to each is decided by a seeded pseudo-random number generator, so results are reproducible rather than different every time.

How YAML Error Injector Works

The input is first parsed to confirm it's valid YAML, since corrupting already-broken input wouldn't produce a meaningful test case. A mulberry32 PRNG seeded with your chosen seed then shuffles the document's non-blank line indices and selects the first N (your error count) as mutation targets.

For each targeted line, the PRNG also picks which of the three mutation strategies to try first; if that strategy doesn't apply to the line's content (for example, trying to delete a colon from a line that has none), the tool falls back to the next strategy in a fixed rotation before giving up on that line.

When To Use YAML Error Injector

Use it to generate test fixtures for a YAML parser or linter's error-handling code, confirming it reports something reasonable rather than crashing.

It's also useful for demoing or documenting what specific kinds of YAML mistakes look like and how a given tool reports them.

Often used alongside YAML Validator, YAML Formatter & Prettifier and YAML Editor & Viewer.

Features

Advantages

Fully reproducible: the same input, seed, and error count always produce identical output, useful for stable, committable test fixtures.
Targets realistic mistakes (a missing colon, bad indentation, an unbalanced quote) rather than arbitrary character corruption.
Reports exactly how many errors were actually introduced, since not every line supports every mutation.
Runs entirely client-side with no added dependency, so test data never leaves your browser.

Limitations

Not every mutation guarantees the result fails to parse; some corruptions (like a stray space in a spot that doesn't affect structure) can still leave the document valid.
The three mutation types are a deliberately small, representative set, not an exhaustive catalog of every possible YAML syntax error.
Very short documents (few non-blank lines) may not support the full requested error count, since each line receives at most one mutation.

Examples

Deleting a colon

Invalid input

replicas: 3

Parser error

replicas 3

Removing the colon turns a valid mapping entry into a line YAML can no longer parse as a key/value pair.

Corrected version

replicas: 3

Unbalancing a quote

Invalid input

name: "api"

Parser error

name: api"

Removing one quote character leaves an unterminated string, a common real-world YAML mistake.

Corrected version

name: "api"

Best Practices & Notes

Best Practices

Commit both the seed and error count alongside any generated fixture, not just the output, so it can be regenerated or adjusted later.
Verify the corrupted output actually fails parsing (with the YAML Validator) when you need a guaranteed-invalid fixture, rather than assuming every generated case does.
Try several different seeds when building a small test suite, to cover a variety of specific corruption patterns rather than relying on just one.

Developer Notes

The PRNG is a self-contained mulberry32 implementation (no dependency), chosen for being small, fast, and producing well-distributed output from a 32-bit integer seed, exactly the properties needed for reproducible test-fixture generation. Line selection uses a seeded Fisher-Yates shuffle over non-blank line indices rather than repeated random sampling, which guarantees no line is targeted twice and keeps the algorithm's behavior easy to reason about.

YAML Error Injector Use Cases

Generating reproducible broken-YAML fixtures for a parser or linter's test suite
Demonstrating how a specific tool reports different categories of YAML syntax errors
Fuzz-testing error-handling code paths with a variety of seeded corruption patterns
Building training or documentation examples of common YAML mistakes

Common Mistakes

Assuming every requested error is guaranteed to break parsing, check `appliedCount` and, if it matters, verify with the YAML Validator.
Using a different seed each time and expecting reproducibility, the seed is exactly what makes output reproducible; keep it fixed to regenerate the same fixture.
Requesting more errors than the document has non-blank lines and being surprised the applied count is lower than requested.

Tips

Pair with the YAML Validator to confirm and inspect exactly why the corrupted output fails to parse.
Use Random YAML Generator first if you need a fresh valid document to corrupt rather than writing one by hand.
Try a handful of different seeds if a single seed's corruption pattern doesn't produce a broken document, some line/mutation combinations don't affect validity.

YAML Error Injector