Parsers get tested against valid input and shipped. Then a truncated upload arrives, or a JSON body with a duplicate key, and the error message is a stack trace. Each case here is annotated with what is wrong so you can check the message you produce matches.
What you can control
- Seven formats, each with six fault types applied to it.
- Truncated cases simulate an interrupted upload — the most common real-world corruption.
- Duplicate keys are valid JSON syntax with undefined behaviour, and parsers genuinely disagree about them.
- Each case is labelled with its fault so a failing test names the actual problem.
What this is not
These break parsers, which is the point. Do not feed them into a production pipeline unless you are deliberately testing its error handling in an environment you can reset.
Questions
Why test malformed input?
Because it arrives. A truncated upload, a mis-encoded export, a hand-edited config — all of them reach parsers, and the difference between a clear error and a stack trace is whether you tested for it.
Are duplicate JSON keys actually invalid?
The grammar permits them; the specification leaves the behaviour undefined. Most parsers keep the last value, some keep the first, and a few error. That disagreement is worth knowing about.
What is a lone surrogate?
Half of a UTF-16 surrogate pair with no partner. It cannot be encoded as valid UTF-8, so it breaks any round trip through a byte-oriented layer.