A ZIP file that will not open is one of the more alarming computer problems, because the contents feel simultaneously present and unreachable. The good news is that most causes are not corruption at all — they are compatibility, encoding or size limits, and the data is completely intact. This page works through every cause, how to identify yours, and what actually recovers data when the file is genuinely damaged.
First, check two things
Compare the file size against the source — a truncated download is by far the most common cause, and a ZIP stores its index at the end, so losing the last few bytes makes the entire archive unreadable. Then try opening it with 7-Zip, which handles almost everything Windows Explorer cannot.
Why the end of the file matters so much
Understanding one structural detail explains a whole family of ZIP problems.
A ZIP archive stores each file's data sequentially, and then — at the very end — writes a central directory: an index listing every entry, its compressed size, and its byte offset within the file. Readers open a ZIP by seeking to the end, finding the directory, and using it to locate everything else.
This design is why an archive can be updated by appending, and why a self-extracting executable can have a ZIP glued onto its end and still work. It also means that losing the last few bytes makes the whole file unreadable, even when 99% of the data is perfectly intact. A truncated download is not gradually damaged; it is completely unopenable.
It also explains the repair strategy below: if the data is present but the index is gone, the index can be rebuilt by scanning forwards for the individual file headers.
Incomplete downloads
| Symptom | Likely cause |
|---|---|
| "Cannot open file: it does not appear to be a valid archive" | Truncated — the index is missing |
| "Unexpected end of archive" | Truncated partway |
| Opens, but the last file fails | Truncated near the end |
| Downloaded size differs from the stated size | Definitely truncated |
⚠️ A "successful" download can still be truncated
A dropped connection, a proxy timeout or a full disk can end a download early while the browser reports it as complete. The file exists and looks plausible in the folder. Always compare the byte count, and prefer a download manager or curl -C - for large files so an interrupted transfer can resume rather than silently finish short.
Encryption that Windows cannot read
This is the most misdiagnosed ZIP problem, because the error message actively points you in the wrong direction.
ZIP supports two encryption schemes. The original ZipCrypto dates from 1990 and is cryptographically broken — it can be defeated in seconds with a known-plaintext attack. AES-256 was added later and is genuinely secure. 7-Zip and WinRAR default to AES.
Windows Explorer only supports ZipCrypto. Presented with an AES-encrypted archive, it cannot decrypt it and reports the file as invalid or the password as incorrect. Both messages are wrong: the file is fine and the password is right.
| Tool | ZipCrypto | AES-256 |
|---|---|---|
| Windows Explorer | Yes | No |
| macOS Archive Utility | Yes | No |
| 7-Zip | Yes | Yes |
| WinRAR | Yes | Yes |
| Keka, The Unarchiver | Yes | Yes |
unzip (Info-ZIP) | Yes | Usually not |
So: if a password-protected ZIP will not open in Explorer, install 7-Zip and try there before concluding anything is wrong. And if you are creating an encrypted archive for someone else, either use AES and tell them they need 7-Zip, or accept that ZipCrypto offers essentially no real protection.
🚨 ZipCrypto is not security
ZipCrypto can be broken without knowing the password, given a small amount of known plaintext — and an archive containing any common file type provides that. Publicly available tools do it in seconds. If you are protecting anything that matters, use AES-256 with a strong passphrase, or use a proper encryption tool rather than an archive format.
Size limits and ZIP64
The original ZIP specification used 32-bit fields, which imposes hard limits:
| Limit | Original ZIP | ZIP64 |
|---|---|---|
| Archive size | 4 GB | 16 EB |
| Single file size | 4 GB | 16 EB |
| Number of entries | 65,535 | Effectively unlimited |
ZIP64 extends all three, and every modern tool supports it. Older tools and some programming-language libraries do not, so an archive above 4GB — or containing more than 65,535 files, which happens easily with a node_modules folder — may open fine in 7-Zip and fail elsewhere.
The 65,535-entry limit is the one that catches people out, because the archive can be small. If a ZIP full of many tiny files fails while a larger one works, entry count is the likely explanation.
Mangled filenames
The original ZIP format had no way to declare the encoding of filenames. Tools stored them in whatever code page the local system used — CP437 in DOS, CP1251 for Russian Windows, Shift-JIS for Japanese — and readers guessed.
The result is filenames that decode into nonsense on a system with different regional settings. The file contents are unaffected; only the names are wrong, which is worth knowing before you panic.
A later revision added a flag bit declaring names to be UTF-8, and modern tools set it. Archives created by older software, or by tools that ignore the flag, still produce mangled names.
Path length and illegal characters
Windows historically limited full paths to 260 characters. An archive whose internal paths are long — a JavaScript project, a deeply nested export — extracted into an already-deep folder blows through that limit, and extraction stops partway with an unhelpful error.
A second problem: archives created on Linux or macOS can contain filenames Windows cannot represent at all — a colon, a question mark, an asterisk, or a name differing only by case (README and readme in the same folder). Extraction either fails or silently overwrites one file with the other. 7-Zip handles this more gracefully than Explorer, usually by renaming.
When it is not a ZIP at all
Extensions are labels, and they lie. Check the actual bytes:
| First bytes | Reads as | Actually a |
|---|---|---|
50 4B 03 04 | PK.. | Real ZIP |
52 61 72 21 | Rar! | RAR renamed |
37 7A BC AF | 7z… | 7-Zip archive |
1F 8B | — | GZIP |
3C 21 44 4F | <!DO | An HTML error page |
That last row is worth watching for. A download that returns an error page — a login redirect, a rate limit, an expired link — is saved with the filename you requested. You get a 3KB "archive.zip" that is really HTML saying "Access denied". Open it in a text editor and the problem explains itself.
💡 PK is Phil Katz
Every ZIP begins with the bytes PK — the initials of Phil Katz, who created the format in 1989. It appears in .docx, .xlsx, .epub, .jar and .apk files too, because all of them are ZIP archives with a defined internal structure.
Split and multi-part archives
Large archives are sometimes split across several files, and every part must be present in the same folder before extraction will work.
| Naming | Created by | Open |
|---|---|---|
.zip.001, .002 | 7-Zip | The .001 file |
.z01, .z02, .zip | WinZip, Info-ZIP | The .zip file |
.part1.rar, .part2.rar | WinRAR | .part1.rar |
Note the reversal: 7-Zip's scheme starts at .001, while the WinZip scheme puts the last segment in the .zip file and you open that one. Opening the wrong part gives an error that looks like corruption.
Repairing a genuinely damaged archive
If the file data is present but the index is damaged, it can often be rebuilt by scanning forwards for the local file headers that precede each entry:
⚠️ What repair cannot do
Every entry in a ZIP carries a CRC-32 checksum of its uncompressed data. If an entry fails that check, the compressed bytes themselves are damaged — and because Deflate is a stream where each block depends on what came before, a single corrupted byte can render the rest of that entry unrecoverable. No repair tool can reconstruct data that is not there.
Repair recovers structure, not content. It works brilliantly for a lost index and not at all for damaged compressed data.
macOS quirks
Two macOS behaviours cause confusion in both directions.
Archives created on macOS contain a __MACOSX folder and files beginning with ._. These hold extended attributes and resource fork data. They are harmless and invisible on macOS, and clutter every extraction on Windows. To avoid creating them:
Archives opened on macOS go through Archive Utility, which is silent about problems. It quietly leaves a partially extracted folder when it hits an error, and gives no indication which files failed. If an extraction on macOS produces fewer files than expected, try unzip -t in Terminal — it reports each failure explicitly.
Diagnostic order
- Compare the file size to the source. Truncation is the most common cause.
- Check the first bytes.
PKmeans a real ZIP;<!DOmeans you downloaded an error page. - Try 7-Zip. It handles AES, ZIP64, long paths and odd encodings that Explorer cannot.
- Test rather than extract.
unzip -tor7z treports exactly which entries fail. - Extract to a short path such as
C:\xif it fails partway. - Check for other parts if the name has a numeric suffix.
- Attempt repair with
zip -FFif the index is damaged. - Re-download if CRC errors appear. That data is genuinely gone.
Verify a download before you trust it
Generate MD5, SHA-1 or SHA-256 checksums in your browser and compare them against the publisher's — no upload, so it works on files of any sensitivity.
Open the Hash Generator →Summary
- The index lives at the end of the file, so a truncated download breaks everything.
- Windows cannot read AES-encrypted ZIPs and blames your password instead. Use 7-Zip.
- ZipCrypto provides no real security. Use AES-256 or a proper encryption tool.
- 65,535 entries and 4GB are the limits without ZIP64.
- Mangled filenames are an encoding issue — the file contents are fine.
- Extract to a short path when extraction fails partway on Windows.
zip -FFrebuilds a lost index but cannot repair damaged data.- Check the first four bytes before assuming corruption — it may be an HTML error page.
Frequently Asked Questions
Why does Windows say my password-protected ZIP is invalid?
Windows Explorer only supports the original ZipCrypto encryption, not the AES encryption that 7-Zip and WinRAR use by default. An AES-encrypted archive is a perfectly valid ZIP that Explorer cannot decrypt, so it reports the file as invalid or the password as wrong. Open it with 7-Zip and the same password works.
How do I know if my ZIP download was incomplete?
Compare the file size against the source — even a few bytes short means truncation. A ZIP stores its index at the end of the file, so a truncated download loses the index and the archive appears completely unreadable even though most of the data is present. The fix is to download it again, ideally with a tool that can resume.
Why are the filenames in my ZIP full of strange characters?
The ZIP format has no reliable way to declare the character encoding of filenames. Archives created on a system using a regional code page store names in that code page, and a machine with different regional settings decodes them incorrectly. The data inside the files is unaffected — only the names are wrong.
Can a corrupted ZIP be repaired?
Sometimes. If the central directory at the end is damaged but the file data is intact, 'zip -FF broken.zip --out fixed.zip' rebuilds the index by scanning for local file headers and often recovers most of the contents. If individual files fail their CRC check, that data is genuinely damaged and cannot be reconstructed.
Why does extracting fail partway through on Windows?
Usually the path length limit. Windows historically capped paths at 260 characters, and a deeply nested archive extracted into an already-deep folder exceeds it. Extract to a short path such as C:\\x instead, or use 7-Zip, which handles long paths correctly.