A ZIP error does not always mean the files inside are gone. Sometimes the archive’s index is damaged while the compressed data remains readable; sometimes the data itself has changed. Those are different failures, and a repair utility cannot recreate bytes that no longer exist.
This guide starts with a safe triage path, then explains what common checks and repair commands can establish. I also tested three controlled damage patterns on a tiny synthetic archive. The results are useful as examples, not a promise about your files.
Start with a safe copy
- Keep the original ZIP untouched. Copy it to a new folder and work on the copy.
- If it came from a download, cloud sync, email, USB drive, or network share, obtain a fresh copy first. Compare file size or a publisher-provided checksum when available. A checksum only helps if you have a trusted value from the source.
- Check whether it is a split archive. Info-ZIP split archives commonly use a final
.zipfile plus pieces such as.z01and.z02. Keep all pieces together and do not rename or concatenate them unless the archive creator’s instructions say to. - Use an up-to-date extractor, and extract to a new empty folder. Do not open or run files from an archive you do not trust.
A ZIP is a structured container: each member has a local header and data, while a central directory near the end records names and other information used for extraction. That structure explains why an archive can have a broken listing but still contain some intact file data. The Library of Congress describes these components and notes that ZIP can also contain encrypted members and use different compression methods.[1]
Read the error as a clue
| Message or symptom | Likely problem | Best first move |
|---|---|---|
| “End-of-central-directory signature not found” or “cannot find zipfile directory” | The directory at the end may be missing, truncated, or unreadable. | Re-download or copy again. If that fails, try a repair scan on a copy. |
| “Bad CRC,” “CRC failed,” or “checksum error” for a named file | The extracted bytes do not match the checksum recorded for that member; the compressed payload or transfer may be damaged. | Get a fresh source copy. A directory-rebuild option cannot restore changed payload bytes. |
| “Unexpected end of archive/data” | The file may have been cut off, or a later split volume may be missing. | Check the download size and every expected volume before repair. |
| “Unsupported compression method” or an encryption/password message | The tool may be too old or may not support the archive’s compression/encryption setting. This is not proof of corruption. | Try a current compatible archiver; confirm the password separately. |
| It opens, but files are missing or unreadable | Some directory records, headers, or individual data streams may be damaged. | List and test the archive, then recover intact members individually. |
CRC-32 is an error-detection check, not a cryptographic authenticity check. A passing test is useful evidence that an entry matches its stored CRC; it does not prove who created the archive or that it is safe.
Repair a copy with Info-ZIP
On macOS or Linux, if Info-ZIP’s zip utility is installed, try the less aggressive scan first. Run this from the folder containing your copied archive:
unzip -t damaged.zip
zip -F damaged.zip --out repaired
unzip -t repaired.zipInfo-ZIP documents -F for archives whose structure is mostly intact. If entries are missing or the ending is truncated, its more aggressive -FF mode scans for member signatures:
zip -FF damaged.zip --out rebuiltDepending on the damage, -FF can ask whether the archive is a single-disk archive or whether more split pieces are available. Answer only from what you know about the archive; do not treat an unknown prompt as a reason to guess. It may produce an incomplete or inconsistent archive. Compare the recovered file list with what you expected, then test every entry:
unzip -l rebuilt.zip
unzip -t rebuilt.zipThe command writes a new output archive, leaving the source path unchanged. If your installed version behaves differently, check its local zip -h2 help. Info-ZIP explicitly warns that its fix modes do not recover entries with bad checksums or otherwise damaged data, and that -FF can misidentify signatures in some embedded-archive cases.[2]
What a small reproducible test showed
On October 12, 2026, I used Apple’s Info-ZIP zip 3.0 and unzip 6.00 on macOS 26.6.2. The synthetic archive held two harmless text files. I made three copies: removed 40 bytes from the end, flipped one byte inside a compressed payload, and overwrote the first local-header signature. I tested each input and repair output with unzip -t.
| Controlled damage | Observed result | What it means |
|---|---|---|
| Last 40 bytes removed, including the end record | unzip -t could not find the directory. zip -FF rebuilt an archive; both test entries passed. |
A missing index can sometimes be rebuilt when member headers and data remain intact. |
| One byte changed inside compressed data | The original and the -F output both reported a CRC error for that member. |
Rebuilding directory information did not repair the changed content. |
| First member’s local-header signature overwritten | -F output retained the second member, which passed; the first member was omitted. |
Partial salvage can be useful, but a successful command does not mean every entry survived. |
This is a demonstration with one tiny archive and three deliberately simple faults. Real archives vary in compression, encryption, metadata, size, and damage pattern, so these results are not a repair-rate comparison and cannot predict your result. On this same CRC-damaged sample, macOS ditto -x -k exited with code 0 but wrote bytes that differed from the original; Python’s zipfile.testzip() identified sample.txt as the first bad member. That is why checking the extracted content matters more than relying on a success message or exit code alone.
If you prefer a graphical tool
For an intact but hard-to-open ZIP, first try a current version of 7-Zip and use its Test action before extraction. The official recovery instructions on 7-Zip’s site describe recovery for the 7z format, not a general repair procedure for ZIP files; do not assume that page promises ZIP reconstruction.[3]
WinRAR documents a Repair command for ZIP and RAR archives. It writes a separate rebuilt archive, and its documentation says the outcome depends on the archive type and the location and size of the damage. Its FAQ also distinguishes ZIP from RAR: RAR can include a recovery record, while ZIP does not provide that same WinRAR recovery-record feature.[4] Treat any rebuilt file as a candidate: inspect the file list, extract into a fresh folder, and open important documents to verify them.
What repair cannot do
There are three different goals that repair guides often blur together:
- Rebuild the archive index: recreate enough directory records to make intact members visible.
- Salvage intact members: extract files whose own headers and compressed streams still work.
- Reconstruct damaged content: infer missing or corrupted bytes from surrounding data. This is a specialized forensic task, not what an ordinary ZIP repair button does.
A 2017 Korean security paper presents a method for restoring a damaged ZIP to a structurally normal archive, highlighting that meaningful information can exist outside the compressed payload too.[5] A separate 2011 Digital Investigation paper studies reconstruction inside corrupt DEFLATE streams using synchronization and language models. Its technique is specialized and inference-based; it should not be mistaken for a guarantee that arbitrary PDFs, photos, databases, or encrypted files can be restored.[6]
If a file still fails CRC after a fresh download and a repair attempt, look for another copy, version history, backup, or the original uncompressed file. If the storage device is failing, stop repeatedly scanning it: copy recoverable data to another drive or consult a data-recovery specialist. ZIP repair changes the container; it does not fix a failing disk.
A short decision path
- Only one download or copy fails? Download or copy it again and compare a trusted hash if available.
- Is it split into volumes? Confirm every volume is present and belongs to the same archive.
- Does the error name CRC or data corruption? Find a clean copy first; try extracting other intact members from a duplicate if needed.
- Does only the end directory appear missing? Try
zip -Fon a copy, then-FFif needed, and test every output entry. - Does the rebuilt archive list nothing or omit expected files? Stop and seek a better source copy; a repair report is not proof of recovery.
Sources and further reading
- Library of Congress, ZIP File Format (PKWARE) — file structure, central-directory role, compression/encryption options, and CRC-32.
- Info-ZIP
zip(1)manual — documented behavior and limits of-Fand-FF. - 7-Zip: How to recover corrupted 7z archive — format-specific instructions for 7z, not ZIP.
- WinRAR Help and Support FAQ — licensing and ZIP/RAR recovery-record distinction; see also Repair archive documentation.
- 정병준·한재혁·이상진, “손상된 ZIP 파일 복구 기법,” 정보보호학회논문지 27(5), 1107–1115 (2017). KCI record and abstract.
- Ralf D. Brown, “Reconstructing corrupt DEFLATEd files,” Digital Investigation 8, Supplement, S125–S131 (2011). DOI and abstract.
Test note: the sample described above was generated locally for this article; no customer or personal files were used. Tool behavior can vary by version and by the exact damage.