How to create an invalid JSON file for testing

Testing that your code handles good JSON is the easy half. The half that ships bugs is what happens when the JSON is malformed, and "malformed" is not one condition, it is at least four, each caught by a different layer of your stack.

Knowing which one you are testing is the difference between a meaningful test and one that passes for the wrong reason.

Four kinds of broken, and what each one proves

This generator offers all four for JSON, and the damage is applied to the bytes rather than to the file name, so a parser rejects the file for the reason you expect.

• Invalid. Structural or data-type errors inside otherwise readable text: a trailing comma, an unquoted key, a string where a number belongs. This is caught by your JSON parser, and it is what most "invalid JSON" tests actually mean.
• Corrupted. The beginning of the file is damaged, so a parser fails on the first token rather than deep inside. This tests your error handling when nothing can be recovered at all.
• Incomplete. The file is cut off part-way through, as happens with a dropped connection or a killed process. Brackets are left unclosed. This is the condition streaming parsers and retry logic get wrong.
• Empty. Structurally valid with no data at all: []. Not broken, and the case most often forgotten, because code that assumes at least one record throws on it.

The invisible one: a byte-order mark

The trap worth knowing about is a file that looks perfectly valid in every editor and still fails to parse. A UTF-8 byte-order mark is three bytes, EF BB BF, placed before the opening brace. Editors hide it. Parsers do not.

JavaScript's JSON.parse throws on a leading BOM, and Python's json module rejects it when the file is read as UTF-8 rather than utf-8-sig. If you have ever received a JSON file that a colleague swears is fine, this is usually why.

The same three bytes break other formats in the same invisible way: a CSV whose first column header no longer matches, and a shell script whose shebang is no longer the first thing in the file.

Encoding is a separate axis from validity

A JSON file can also be technically valid but encoded in a way your reader does not expect. UTF-16 doubles every ASCII character into two bytes, so the file is full of interleaved zero bytes and any code reading it as UTF-8 sees garbage.

One structural consequence is useful to know: a UTF-16 file always has an even number of bytes, because every character occupies a two-byte unit. An odd byte count in a UTF-16 file means the file is truncated.

Encoding is offered here as a separate control from the broken conditions, so you can produce a corrupted UTF-16 file and have it be genuinely corrupt in its real bytes rather than merely mislabelled.

What to assert

• The parse fails, and fails with an error your code recognizes, not an unhandled exception reaching the user.
• The failure is reported with enough context to act on: which file, and ideally where it broke.
• Nothing was partially written or partially committed as a result of the failed parse.
• The empty case ([]) is handled as "no records", not as an error and not as a crash.

Common questions

What is the simplest invalid JSON?

A trailing comma after the last element, or a single unmatched brace. Both are rejected by every conforming parser, which makes them good smoke tests, but they only exercise the parser, not your handling of truncated or corrupted input.

Is an empty file valid JSON?

No. A zero-byte file is not valid JSON, because JSON requires a value. An empty array or object is valid and is the case worth testing separately, since code that expects records often fails on it.

Why does my JSON fail to parse when it looks correct?

Most often a byte-order mark: three invisible bytes before the first brace that editors hide and parsers reject. Failing that, check for a truncated end or a non-UTF-8 encoding.

Generate an invalid JSON file →

Formats mentioned here: JSON test files · JSONL test files · CSV test files · XML test files · YAML test files

More guides

How to create a very large test file · How to make a corrupted file for testing · How to test file upload validation · Filename test cases that break real systems · Encoding test files: UTF-16, BOM and Latin-1