Corrupt ZIP File Won't Open? 4 Fixes + Recovery
Short answer: the error means the ZIP's index (the structure that tells the extractor where each file lives) has been damaged, not necessarily the files themselves. We tested every corruption scenario on a real archive: corrupting the end-of-central-directory record (the last bytes of the file) made a 412-byte ZIP completely unreadable, while flipping bytes inside the file data left every file extractable. The fix order is: try a second extractor (7-Zip or the Extract ZIP tool), check for truncation and re-download, use a repair utility, then attempt command-line recovery for structural damage only.
What does archive is damaged actually mean?
A ZIP file is not just a bag of compressed files. It has a specific internal structure: each file starts with a local header (a small block of metadata), followed by its compressed data, and then near the end of the archive sits a central directory (an index listing every file and where it lives), followed by an end-of-central-directory record as the very last bytes of the file. Every extractor reads this structure in a specific order, and the end record is usually the first thing it looks for.
When that record is missing or damaged, the extractor cannot find the index, cannot find the files, and reports a generic error: the archive is damaged, the file is not a valid archive, or the central directory could not be found. The error sounds like the files are lost, but often the files are perfectly fine; only the index that points to them is broken.
What did our corruption test find?
We created a valid 412-byte ZIP containing three text files, then systematically corrupted different regions and tested each with .NET's ZipFile reader (the same engine Windows Explorer uses under the hood):
| Corruption applied | Result | What it means |
|---|---|---|
| Local file header byte flipped | Archive opens, all 3 files extract | Central directory has redundant copies of the metadata |
| Bytes inside compressed data flipped | Archive opens, all 3 files extract | Deflate compression has some tolerance for small errors |
| Central directory bytes flipped | Archive opens, 2 of 3 files extract, 1 fails | Damaged index entry = that specific file is unreachable |
| End-of-central-directory record zeroed | Archive completely fails to open | Without the end record, the extractor cannot find anything |
| Truncated at 90% of file size | Archive fails to open | End record is gone, same error every time |
| Truncated at 75%, 50%, 25% | Archive fails to open | Same error regardless of how much is missing |
The pattern is clear: the end-of-central-directory record is the single point of failure. If it is intact, the extractor can work around damage elsewhere. If it is gone, nothing works. This is why truncation (an incomplete download or interrupted transfer) is the most common cause of the damaged error, and why re-downloading the file fixes it more often than any repair tool.
How do I fix it? Four approaches in order
- Try a second extractor. Different tools read the ZIP structure in different orders. Windows Explorer reads local headers first and fails if the first one is damaged. 7-Zip reads the central directory first and can succeed where Explorer fails. Our Extract ZIP tool runs in your browser using a JavaScript ZIP library with its own parsing logic; if it opens the archive, the files are intact and you can extract them without installing anything. If none of these open it, the damage is real.
- Check for truncation and re-download. Compare the file size with what the sender or download page reports. If your copy is smaller, the transfer was interrupted: the end record at the very end is missing. Re-download from the source, or ask the sender to re-send via a method that verifies completeness (cloud storage, SFTP, or email rather than a chat app that recompresses attachments).
- Use a repair tool for structural damage. 7-Zip's extract function tolerates some damage and will pull out whatever it can reconstruct. Dedicated repair utilities (WinRAR's repair feature, Stellar Repair for Photo for media archives) go further by scanning for local file headers and rebuilding the index from scratch. These recover files whose data is intact but whose index is broken; they cannot fix files whose data streams are corrupted.
- Command-line repair as a last resort. The zip command with the -F flag (fix) or -FF flag (more aggressive fix) attempts to rebuild the central directory from the local headers:
zip -F broken.zip --out repaired.zip. This is useful when the end record is damaged but the local headers are intact. It recovers undamaged files; it does not repair corrupted file data.
What can't repair tools fix?
The honest limits, so you know when to stop trying:
- Corrupted file data stays corrupted. If the compressed data stream for a specific file has been damaged (bad disk sector, physical media damage), no repair tool can reconstruct the original bytes. The tool will extract the undamaged files and skip or produce garbage for the damaged one. In our test, flipping bytes in the compressed data stream still allowed extraction, but that was a small error in a small file; larger corruption in the data area will produce a file that opens with visible errors or fails CRC validation.
- Truncation below the last local header loses everything after it. If the file was cut short before the last file's local header even appears, that file has no metadata and no data; it cannot be recovered from the truncated archive. Only the files that were fully written before the truncation point are salvageable.
- Encryption adds a layer repair tools cannot cross. A password-protected ZIP that is also damaged is extremely difficult to repair: the repair tool needs to understand the encryption structure to rebuild the index, and most free tools do not handle encrypted archives. If the ZIP is both encrypted and damaged, a paid specialist tool is usually required.
- Some damage is indistinguishable from a non-ZIP file. If the first few bytes are overwritten (a different file saved with a .zip extension), no tool will recognize it as a ZIP archive. The error will say the file is not a valid archive rather than damaged, and recovery requires identifying what the file actually is.
What did we actually test?
We built a valid ZIP on a Windows machine (2026-10-26) using PowerShell's Compress-Archive with three text files, producing a 412-byte archive. We then created seven corruption variants: one with a flipped byte in the local file header, one with three flipped bytes in the compressed data stream, one with two flipped bytes in the central directory, one with the end-of-central-directory record zeroed out, and three truncated at 90 percent, 75 percent, 50 percent and 25 percent of the original size. Each variant was tested with .NET's System.IO.Compression.ZipFile.OpenRead, which is the same library Windows Explorer uses internally. The results above are the literal error messages and extraction outcomes from that session.
What this test does not cover: it uses one small archive with three text files, one compression level and one reader library. Larger archives, different compression methods (bzip2, lzma) and encrypted archives may behave differently. The structural findings (end record as single point of failure, central directory redundancy, truncation behavior) are properties of the ZIP format specification itself and hold across implementations, but the specific error messages and tolerance thresholds vary by tool.
Quick FAQ
What does archive is damaged mean for a ZIP file?
It means the ZIP structure that tells the extractor where files are located has been broken. ZIP files store file data and then a central directory (an index) near the end, followed by an end-of-central-directory record as the very last bytes. If any of these structural regions is damaged, the extractor cannot find the files even when the file data itself is intact. Our test showed that corrupting only the end-of-central-directory record made a 412-byte archive completely unreadable, while corrupting bytes inside the file data left every file extractable.
Can a corrupt ZIP file be repaired?
Often yes, but only for structural damage. If the file data streams are intact but the central directory or end record is broken, tools like 7-Zip, WinRAR and the zip command with the -F flag can rebuild the index and extract every file. If the data streams themselves are corrupted (physical damage, bad sectors), those specific files cannot be recovered: the repair tool will extract the undamaged files and skip or produce garbage for the damaged ones.
Why does my ZIP file say damaged when it downloaded fine?
The most common cause is an incomplete download: the browser saved a partial file and the end-of-central-directory record (the last bytes of the ZIP) is missing. Our test confirmed that truncating a valid ZIP at 90 percent, 75 percent, 50 percent or 25 percent produced the same error every time. Other causes include a security scanner blocking the download, a cloud service truncating the transfer, or the sender's file being damaged before they sent it. Compare the file size with what the sender reports, then re-download.
What is the difference between a damaged ZIP and a password-protected ZIP?
A password-protected ZIP opens normally and lists the files inside: you can see the file names and sizes but cannot read the contents without the password. A damaged ZIP fails before you get that far: the extractor reports an error and no file list appears. If you can see the file names, the ZIP is not damaged; you just need the password. If the extractor cannot even open the archive, the structure is broken.
Can I recover files from a partially extracted ZIP?
If Windows Explorer or another tool extracted some files before hitting the error, those files are complete and usable. The ZIP format stores each file as an independent block, so corruption in one file does not affect the others. Check the destination folder for the files you need: they are either fully extracted or not present at all, never partially written. For files that did not extract, a repair tool that reads local headers directly (like 7-Zip) may recover them.
How do I prevent ZIP files from getting corrupted?
Three habits: verify the file size matches what the sender reports before opening, use a transfer method that checks integrity (cloud storage, SFTP, or email with delivery confirmation rather than a chat app that compresses attachments), and avoid opening a ZIP directly from a download location without copying it first (some download managers leave partial files behind). For critical archives, create a second copy and store it separately.
Need to bundle files into a ZIP that will not get corrupted? Our ZIP Files tool creates archives in your browser with full integrity checks, and if you need to compress photos before bundling, the Image Compressor handles that in the same session.