In short
This tool generates files that are broken on purpose. Pick a format and a damage mode and it constructs a real, valid file in the browser, breaks one named part of its structure, and downloads the result — with a short note describing precisely what it did. Nothing is uploaded and nothing on your disk is touched; the bytes are built from scratch each time you click.
Why deliberately-corrupted test files matter
Software that reads files has to cope with files that are wrong: a download that stopped halfway, a byte flipped in transit, an archive whose index never got written. But damaged inputs are awkward to come by on demand, and "just delete some bytes" produces unpredictable, hard-to-describe breakage. A generator that damages one specific structural element — and tells you which — gives you reproducible fixtures you can commit, cite in a bug report, and reason about.
Each sample here starts fully valid. The ZIP carries a correct CRC-32 over real stored data; the PNG has a valid 8-byte signature, an IHDR with real geometry and a proper stored-deflate IDAT; the PDF has a genuine cross-reference table with accurate offsets; the DOCX is a well-formed OOXML package. Only then is a single element broken, so the difference between "valid" and "corrupt" is exactly one known change — which is what makes it a useful test.
What each mode breaks
ZIP & DOCX — index loss
The archive's end-of-central-directory record is zeroed or truncated (ZIP), or the central directory itself is zeroed (DOCX). The entries and their local headers survive, so this is the classic case a good repairer rebuilds around. A DOCX is an OOXML package, which is a ZIP, so it fails and recovers the same way.
PNG — chunk damage
Either the IHDR chunk's CRC is flipped, so a strict decoder rejects an otherwise-fine header, or the file is truncated just before its IEND terminator, mimicking an interrupted download. Both are common, distinct failure signatures for a reader to detect.
PDF — trailer damage
Either every cross-reference offset is rewritten to point past the end of file, so the xref table is present but useless, or the startxref pointer and the %%EOF trailer are removed entirely, so a reader can't find where the cross-reference begins.
How to test a repair or inspection tool with these
Generate a sample and read the note beneath the button — it names the exact damage. Feed the file to the tool under test and check two things. First, detection: does it identify the specific failure, or does it crash, hang, or silently accept a broken file? Second, recovery: for the index-loss samples, whose data survives, does it produce a file that opens correctly? You can cross-check detection against IntactFile's own read-only structure inspectors, which name the same classes of damage, and then try a rebuild with therepair tools.
Why "no upload" is verifiable, not a slogan
Every sample is assembled from raw bytes by JavaScript running on your machine and delivered through an in-memory Blob URL; the page makes no request that carries any data. You don't have to take that on faith — open DevTools, select the Network tab, and generate a file: nothing goes out. The same principle underpins IntactFile's inspection and repair tools, which read your files locally rather than uploading them.