How to make a corrupted file for testing
"Corrupted" gets used for any file that will not open, which is why corruption tests so often prove nothing. A file with a wrecked header, a file with bad data in the middle, and a file that simply stops early fail in different components, and code that survives one can still fall over on the next.
If you want the test to mean something, pick the failure deliberately.
Renaming a file is not corrupting it
The most common mistake is renaming photo.png to photo.pdf and calling it corrupt. That is a type mismatch, and it is worth testing, but it tests extension and MIME checking, not corruption handling.
A reader that identifies files by content sees a perfectly intact PNG and reports the wrong type, which is a completely different code path from one that finds a PDF with an unreadable cross-reference table. Both are valid tests. They are not the same test.
The three real conditions
Every format on this site can be generated in all three conditions, alongside the valid version, so you can hand the same logical file to your pipeline four ways and compare the results.
- Corrupted. The header or magic bytes at the start are destroyed. The file cannot be identified, so it fails at the earliest possible point. This is what you want for testing "we could not read this file at all" paths.
- Invalid. The container is intact and identifiable, but the contents violate the format: bad field values, broken structure, wrong data types. The file gets past type detection and fails during parsing, which is a deeper and usually less-tested path.
- Incomplete. A genuine prefix of a valid file, cut off part-way. Everything read so far is correct, and then the data stops. This is what an interrupted upload or a killed export actually produces, and it is the condition most likely to leave your system holding a half-processed record.
Why truncation deserves its own test
Truncation is the condition real systems hit most and test least, because it is the one that occurs naturally: a network drops, a disk fills, a container is killed mid-write.
It is also the one where formats behave least predictably. Some readers detect it immediately from a length field in the header. Others decode happily until they run out of bytes and then throw from somewhere deep inside a library. A few return partial content with no error at all, which is the outcome most likely to corrupt your database quietly.
For archives and container formats the effect is sharper still, because the index that says where everything lives often sits at the end of the file, so a truncated ZIP loses the directory of its own contents.
What to assert, in order
- The file is rejected, rather than partially imported.
- The error distinguishes "cannot read this file" from "this file is not the type you claimed".
- Nothing was committed: no half-written rows, no orphaned records, no partial writes left behind.
- Temporary files and locks are cleaned up after the failure, not only after success.
- The message shown to a user does not leak a stack trace or a filesystem path.
Common questions
How do I corrupt a file without editing it by hand?
Generate it corrupted in the first place. Pick a format, choose the Corrupted condition, and the file is produced with its header damaged, repeatably and at the exact size you asked for. That is hard to do by hand in a hex editor.
What is the difference between corrupted and invalid?
Corrupted damages the start of the file, so it cannot be identified at all. Invalid leaves the file identifiable but wrong inside, so it fails later, during parsing. They fail in different components of your stack.
Does a corrupted file keep its size?
Yes. Corruption damages bytes in place, so the length is unchanged. That is deliberate: it is what distinguishes it from the incomplete condition, which is shorter than requested because it has been truncated.
Formats mentioned here: PDF test files · ZIP test files · DOCX test files · PNG test files · MP4 test files
More guides
How to create a very large test file · How to create an invalid JSON 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