Why your ZIP file says it is corrupted, and how to fix it

“The archive is either in unknown format or damaged.” “End of central directory not found.” “Cannot open file as archive.” Every extraction tool has its own wording, and none of them tell you which of several unrelated problems you actually have.

There are four, and they need completely different responses. Working out which one you are looking at takes about ten seconds and saves you from downloading repair software you do not need.

1. It is not a ZIP file (the most common by far)

An extension is a label someone typed. It is not the file.

Files get renamed constantly — by download managers, by email clients, by people zipping up a folder of RARs and calling the result photos.zip. And a surprisingly large share of “corrupted ZIP” downloads are not archives at all: the server returned an HTML error page, or a login redirect, and the browser saved it under the filename you asked for. Open that in an extractor and you get a corruption error, because from the extractor’s point of view it is indeed not a valid archive.

Every format announces itself in its opening bytes. A ZIP starts with the characters PK — the initials of Phil Katz, who created the format — followed by two bytes identifying the record type. A RAR starts with Rar!. A 7-Zip archive starts with 7z. A PDF starts with %PDF. Those bytes are the fact; the extension is a guess.

This is the first thing the file.zip inspector checks. It reads the leading bytes of whatever you drop on it, and if the file is not a ZIP it does not say “invalid archive” — it names what the file actually is:

holiday.zip is not a ZIP archive — it is a RAR archive.

Which usually tells you what to do next. If it is a RAR you need a RAR extractor. If it reports that the file looks like plain text, open it in a text editor and you will most likely find an HTML error page explaining that your download failed. If it reports that the file is empty, the download produced nothing at all.

Nothing is uploaded to do this. The check happens in your browser, on the first few hundred bytes.

Worth knowing: quite a few files that are not named .zip are secretly ZIPs. .docx, .xlsx, .pptx, .jar, .apk and .epub are all ZIP containers with a different extension. The inspector opens those happily, because it decides by bytes rather than by name.

2. You are typing the wrong password

Encrypted archives fail in ways that read like corruption. Some tools say “invalid password” and some say the data is damaged, because from the decompressor’s perspective those are hard to distinguish — decrypting with the wrong key produces bytes that make no sense as compressed data.

If the archive prompted you for a password at any point, exhaust that possibility before concluding anything is broken. file.zip handles password-protected ZIP files, and the password is used entirely inside your browser.

3. The download is incomplete

This is real corruption, and it is the ordinary kind: the transfer was interrupted, and you have a prefix of a file.

Here is the awkward part. A truncated ZIP still starts with PK — the beginning of the file is intact, it is the end that is missing. So a bytes check passes and the file still will not open.

The reason is where ZIP keeps its index. Unlike most formats, a ZIP file’s directory of contents is written at the end, not the beginning. That design made sense in the floppy-disk era, since it allows appending to an archive without rewriting it. The consequence is that losing the last few kilobytes of a ZIP costs you the index for the entire thing, even if 99% of the compressed data arrived perfectly.

That is what “End of central directory not found” means, in every tool that says it. It is not a cryptic internal error. It means: this is a ZIP, and the part that says what is in it is missing.

If you see that in file.zip, the file passed the format check and then failed to open — so the file really is a ZIP and really is damaged.

The first thing to try is not repair software. It is downloading the file again, ideally over a wired connection or a different network. An incomplete download is a transfer problem, not a file problem, and the copy at the other end is almost always fine. Compare file sizes if the source shows one; a mismatch settles it immediately.

4. The archive is damaged in the middle

Less common: bit rot on failing storage, a corrupted USB stick, a file mangled by being transferred in text mode by an ancient FTP client. The index is intact, the archive lists its contents, and then individual entries fail their integrity check on extraction.

This is the case where partial recovery genuinely works, because ZIP compresses each entry separately. Damage to one entry does not touch the others.

What actually repairs a ZIP file, and what does not

Be clear about what “repair” can mean. No tool can reconstruct bytes that are not there. If your download stopped at 60%, the missing 40% is missing, and nothing recovers it from the fragment you hold. Any product promising otherwise is selling you the recovery of whatever survived, which is a real but much smaller thing.

What genuinely works:

zip -FF rebuilds a missing or damaged central directory by scanning the file for entry headers, which is precisely the truncated-download case:

zip -FF broken.zip --out fixed.zip

It recovers entries whose compressed bytes fully arrived. Whatever was cut off mid-entry stays lost. On macOS and Linux this ships with the system; on Windows it comes with Info-ZIP.

7-Zip’s partial extraction does the same job through a GUI. Open the archive, extract, and when it reports errors keep the files it managed to produce. For a damaged-in-the-middle archive this often gets you everything except the affected entries.

Re-downloading remains the answer to most of this, and it is worth trying first even though it feels less like solving the problem.

What file.zip does and does not do

Straightforwardly: file.zip diagnoses, it does not repair. There is no reconstruction of a truncated archive, and there is not going to be one — that work belongs in zip -FF, which already does it well.

What the inspector is good for is the ten seconds at the start, which is the step most people skip:

• It reads the leading bytes and tells you whether you have a ZIP at all, naming the real format when you do not.
• It opens the ZIP-based formats that are not named .zip.
• If it is a valid ZIP, it lists the contents — so you can see what you are dealing with before extracting anything.
• If it is a ZIP whose index is unreadable, you learn that it is genuinely damaged rather than merely mislabelled, which is the fact that decides your next move.

Everything happens in your browser. Nothing is uploaded, which matters rather a lot for a broken file you were about to hand to a free online repair service.