IntactFile

Inspect a ZIP file — structure and integrity, nothing uploaded

Find out what's really inside an archive and whether it's intact: every entry, its compression method and sizes, its stored checksum, and a pass/fail integrity check — read locally, in your browser.

Your file never leaves your device — inspection runs in your browser. 0 bytes uploaded.

Drop a ZIP (or DOCX / XLSX / PPTX) file hereTap to choose a ZIP (or DOCX / XLSX / PPTX) file

Reads the local headers, central directory and end-of-archive record, and integrity-checks every entry.

100% in your browser. 0 bytes uploaded — open DevTools → Network and watch. Your file is read, never sent.

In short

This is a read-only inspector for ZIP archives and the Office formats built on ZIP (DOCX, XLSX, PPTX). Drop a file and it scans the structure locally — the local headers in front of each entry, the central directory that indexes them, and the end-of-archive record — then lists every entry and integrity-checks it. Nothing is uploaded and nothing is rewritten; you get a verdict and a report, not a modified file.

What the inspector reads

A ZIP is a row of independently compressed files, each preceded by a small local header, followed by acentral directory — the table of contents — and closed by an end-of-central-directory record. The inspector walks all three: it scans forward for the local headers (so it still finds your files even when the index is gone), locates the central directory and end record, and notes anything out of place — a garbage prefix before the first entry, a truncated tail, an index that points nowhere.

For each entry it then does what a strict extractor does: it decompresses the stored data locally and recomputes the CRC-32 the archive claims. The per-entry table shows the name, the compression method (Store or Deflate, usually), the compressed and uncompressed sizes, the stored checksum, and the result. When something is wrong, the exact reason appears beneath the row — a CRC mismatch with both values, a decoded size that differs from the declared one, an encrypted or unsupported entry.

Reading the verdict

Structurally valid

The records are present and every entry passes its integrity check. If an application still refuses the archive, the fault is there — a stricter parser, a wrong file extension, or a bad copy on the other end — not in these bytes.

Damaged

The report names the class: a missing end record, a broken central directory, a truncated file, a garbage prefix. If the entries themselves survived, this is the kind of damage repair rebuilds around — head to the ZIP repair tool, which starts from this same diagnosis.

Why "no upload" is verifiable, not a slogan

The archive is read with the browser's own file APIs and every parser runs on your machine; the page makes no request that carries your data. You don't have to take that on faith — open DevTools, select the Network tab, drop your file, and watch. This is the same principle behind thezero-upload proof page, applied to inspection.

FAQ

Is my ZIP actually corrupt, or is it my unzipper?

That's exactly what this tells you. The inspector scans the archive's local headers, central directory and end-of-archive record and reports whether the structure is sound. If every entry passes its integrity check and the records are present, the archive is fine and the problem is elsewhere — a strict extractor, a wrong extension, or an incomplete copy on the other machine.

Does the file get uploaded?

No. The archive is read in your browser and the report is built there too — 0 bytes are sent anywhere. You can prove it: open your browser's DevTools, switch to the Network tab, then drop the file and watch that no request carries it.

What does the CRC status mean?

Every file stored in a ZIP carries a CRC-32 checksum of its original contents. The inspector decompresses each entry locally and recomputes that checksum; 'ok' means it matched, and a mismatch is reported with the expected and actual values. A mismatch means that entry's compressed data is damaged, not just the archive's index.

Can it inspect DOCX, XLSX and PPTX files?

Yes. Modern Office files are ZIP packages under the hood, so the same inspector reads them: it will show the internal parts (like word/document.xml) as entries and flag the container type it detected. If those parts are intact, the document's data is intact.

It says an entry is corrupt — can it be recovered?

Inspection only reports; it doesn't change the file. When the damage is a missing or broken index but the entries themselves are intact, the repair tool can rebuild the archive around them. When an entry's own compressed data is corrupt, that entry generally can't be recovered, because DEFLATE carries no redundancy — the inspector is honest about which case you're in.

Other inspectors: PDF ·PNG · or, if the file is damaged,repair a ZIP ·all repair tools