Generate corrupted files for error-path QA testing

A focused tool for generating deliberately damaged files used in error-path QA, parser robustness testing, antivirus / sandbox checks and CDN-resilience tests. Upload any file and apply one of six damage modes — tail or head truncation, zero magic bytes, random bit-flip, middle zero-fill or extension rename. The damaged file is built in your browser and downloaded straight to your device.

How to use

Drop a file into the upload zone — any format up to 500 MB.

Pick a damage mode and adjust percent / flip-count / rename extension.

Hit Generate — the corrupted file is built and saved to your device.

Truncate, zero magic bytes, bit-flip or rename — six damage modes

Drop audio file here or click to browse

Any file up to 500 MB. Damage is applied in your browser.

File: — Size: —

Damage mode

Truncate tail Cut off the last N% of bytes — simulates a network-interrupted download. Truncate head Strip the first N% of bytes — destroys headers and magic numbers. Zero magic bytes Zero the first 16 bytes — file type is unrecognisable but content remains. Bit-flip Flip N random bits across the file — simulates bit-rot and faulty storage. Zero middle Replace the middle N% with zeros — payload structure but no content. Rename only Keep bytes intact, change extension — catches extension-trusting parsers.

Percent (%)

Flip count

New extension

Caution: These files will fail to open in normal viewers. Use them only for testing your own software, never as decoys or attachments — many antivirus tools flag damaged files.

Quick presets:

Features

Six damage modes — tail/head truncation, magic-byte zero, bit-flip, mid-zero, rename Any input file up to 500 MB — JPG, PDF, MP4, DOCX, ZIP, anything Tunable damage — percent for truncation/zero, count for bit-flips Extension rename mode — same bytes, wrong extension to trip MIME sniffers

Frequently Asked Questions

Why test against corrupted files?

Real-world file pipelines deal with truncated downloads (network drops), accidental edits (text editor opened a binary), bit-rot on cheap storage, and users renaming extensions to bypass blocklists. Robust software handles these gracefully — friendly error, no crash, no memory leak. Sad-path testing with these damage modes catches the bugs you would otherwise only see in customer support tickets.

How dangerous is the output?

The output is a benign damaged file — same byte stream as the input with some bytes truncated or flipped. There is no malware injection, no exploit. Most parsers will refuse the file with an error; some may parse partial data and miss the truncation. The output is suitable for QA on your own software and antivirus / sandbox flow testing, not for security exploit work.

Why does "zero magic bytes" only zero out 16 bytes?

File-type magic numbers (the first few bytes that identify JPG, PDF, ZIP etc.) live in the first 4–8 bytes — 16 covers them all with margin. Zeroing more is closer to "tail-truncate from the front" and is what the head-truncate mode does. Keeping magic-byte mode minimal gives you a file that looks similar in size but fails the very first MIME-sniff.

What does "rename only" achieve if the bytes are untouched?

It tests whether your pipeline trusts the extension or the actual bytes. A JPG renamed to .zip should be rejected by a zip parser; a real .exe renamed to .pdf should be rejected by a PDF viewer. Many older codebases trust the extension blindly — this mode catches that bug class without needing to fake the content.

💡 Want us to improve this tool just for you?

We can — and it's free! Just send us a quick message with your idea. If you'd like to discuss it in detail, leave your email and we'll get back to you. You can stay anonymous.

How do you rate this tool?

Thank you for your rating!

Change my rating

Want to leave a comment?

Want to share more? Leave a comment!

Thank you! Your comment will appear after moderation.

Who is this tool for?

Published 21 May 2026