"Unexpected end of archive" — what it means and what still comes out

The exact error, and what it's telling you

Depending on which tool opens the file, the wording changes but the meaning does not. WinRAR shows:

Unexpected end of archive, and often alongside it The archive is either in unknown format or damaged.

7-Zip words the same failure as Unexpected end of data, or, when the damage reaches the front of the file, Cannot open the file as archive. On Linux or macOS, the command-line unzip reports unexpected end of file or the more precise End-of-central-directory signature not found.

Every one of those strings is describing a single situation: the tool ran out of file before the format said it should. A ZIP or RAR has a defined shape, with specific structures that are supposed to sit at known places. When the file is shorter than that shape requires, the tool hits the end unexpectedly and stops. That is what "unexpected" means here. It is not a random glitch, and it is not usually scrambled data. It is a file with its tail missing.

A ZIP keeps its index at the very end

To understand why a missing tail is so disruptive, it helps to know how a ZIP is laid out. An archive is two things stitched together. First come the entries: each file you added, compressed, and written back to back, and each one prefixed by a small local header giving its name and size. Second, after all the entries, comes the central directory: a table listing every file in the archive and the exact byte offset where each one begins.

A ZIP stores the files first and the directory listing them last. A truncated download loses the directory, not the files before it.

The central directory is the archive's index. When you double-click a ZIP, the tool jumps to the end, reads that directory, and uses it to show you the file list. Putting the index last is deliberate: it let the original ZIP format append files to an archive without rewriting the whole thing. The catch is that the one structure a tool needs first is the one structure stored last, so any damage that starts at the end of the file lands squarely on the index. This is the same pattern that makes a spreadsheet fragile, because an .xlsx file is really a ZIP with its own directory at the end.

Why a cut-off download loses the index, not the files

A ZIP is written and transferred front to back. When a download stalls, a cloud sync gives up, or a USB drive is pulled mid-copy, the file that lands on your disk is whatever arrived before the interruption: the front is intact, and the back is simply absent. Because the directory lives at the back, it is the first casualty of any truncation. The entries near the front, the actual compressed files, are sitting there untouched.

That is the whole reason the error is so recoverable. The tool cannot find the directory, so it refuses to open the archive the normal way and reports an unexpected end. But the files themselves were never the problem. A repair pass ignores the missing directory and walks the archive from the front instead, reading each local header, taking the compressed data that follows it, and rebuilding a fresh directory from what it finds. The archive opens again, listing every entry that physically survived.

A quick sanity check tells you truncation from something worse: compare the file size against the original if you know it. A 240 MB archive that arrived as 180 MB is textbook truncation, and the missing 60 MB is not damaged, it is elsewhere. That is also why re-downloading is the first move. The missing bytes still exist at the source, and a clean copy beats any salvage of a partial one. If the archive came from a web download or an email attachment, try that route before you repair. The Windows-specific version of this same story, where Explorer's built-in extractor is stricter than the tools above, is covered in "The Compressed (zipped) Folder is invalid".

Partial extraction: getting out what survived

When a clean copy is not available, partial extraction is the realistic goal, and it is often a very good outcome. Because each entry carries its own local header and its own compressed block, the files stored before the cut are independent of the ones lost after it. A repair tool reads the archive sequentially and recovers each entry until it reaches the point where the data was truncated. The result is not all-or- nothing; it is "42 of 50 files came back," with the missing eight being the ones that were still in transit when the transfer stopped.

There is one edge worth naming honestly. The file that sits right at the cut is often half-present: its header and the first part of its compressed data arrived, but the rest did not. That file may extract as a truncated version of itself, or fail to decompress at all, depending on the format and how far along the cut landed. Everything before it extracts cleanly. So a reasonable expectation is: full files up to the cut, one possibly damaged file at the boundary, and nothing beyond. WinRAR's "keep broken files" option and equivalent settings in other tools exist precisely to write out that boundary file for whatever it is worth.

When it's genuinely hopeless

Structural repair rebuilds the index around surviving data. It cannot manufacture data that is not there, and a few situations are beyond what any tool can do. Being straight about them saves you time:

• The damage is mid-stream, not at the tail. DEFLATE, the compression ZIP uses, has no redundancy: it is a continuous stream where each part depends on what came before. If bytes are corrupted or missing inside a file's compressed block rather than cleanly cut off at the end, decompression loses sync at the damage and everything after that point in the file is unrecoverable. You may still get the start of that file, but not the whole of it.
• The archive is encrypted. A password-protected or AES-encrypted archive can be structurally repaired, its directory rebuilt, its entries relisted, but the compressed data stays encrypted. Without the password, the recovered entries cannot be decrypted into usable files. Repair fixes the container; it does not break the encryption, and no legitimate tool claims otherwise.
• A required part of a multi-part set is missing. A split archive (.z01, .z02, or .part1.rar and friends) stores one continuous stream across several files. If a middle part never arrived, the stream has a real gap, and the volumes after the gap cannot be joined to the ones before it.
• The file is nearly empty. An archive that came back as a few kilobytes of a multi-megabyte original, or that reads as mostly zeros, holds no real entries to recover. That is a download or recovery problem, not a repair problem.

Outside those cases, a truncated archive is one of the friendlier corruption problems to face, because the format's own layout makes the surviving files reachable one at a time.