ZIP Archive Repair (Truncated, Damaged and Broken Downloads)

About the ZIP Archive Repair (Truncated, Damaged and Broken Downloads)

A ZIP archive keeps its table of contents — the central directory — at its very end, and most programs read nothing else. So when a download stops early, a copy is cut short or a disk loses a block, the archive will not open at all, even though nearly everything in it is still there: Windows says the compressed folder is invalid, 7-Zip reports an unexpected end of archive, and unzip cannot find the end-of-central-directory signature.

This page reads the archive the other way, from the front. Every file inside a ZIP starts with a local header that repeats its name, its compression method and — usually — its sizes and checksum, so the page finds each file by its header, decodes it to the end, and compares the result with its CRC-32 checksum. Each file is listed as intact, partly recovered or lost, and the intact ones go into a new, clean archive with their original compressed bytes copied exactly — nothing is recompressed — or straight into a folder. It works for the formats built on ZIP too: JAR, EPUB, APK, ODT and others. Nothing is uploaded: the archive is read on your device, a few megabytes at a time.

Common uses

• Downloads that stopped part way, from a browser, a download manager or a messaging app.
• Archives copied badly from a USB stick, a memory card or a network share.
• Backups and exports that will not open, written by tools that stream their archives.
• E-books (EPUB), Java archives (JAR) and OpenDocument files that their programs call damaged.
• Archives found by a deep scan of a disk image and marked partly damaged.

Why a cut-off ZIP will not open

PKWARE’s specification lays an archive out as a series of files, each a local file header followed by its data, and at the end a central directory listing them all, closed by an end-of-central-directory record (PKWARE APPNOTE). Readers start from that last record, because it says where everything is. Lose the end of the file and they have nothing to start from — even though every file before the cut is still whole.

The local headers are the way back in. Each one starts with the signature 50 4B 03 04 (“PK” and two bytes), and repeats the file’s name, method and flags. That is what this page looks for, through the whole archive.

How each file is found and checked

• Its header gives the name, the method (Stored, Deflate or Deflate64 are decoded here) and, normally, its sizes and its CRC-32 checksum. The central directory, where it survived, supplies what a header left out.
• Its end: from its sizes when they are known. When a program streamed the archive and put the sizes in a data descriptor after the data, the page decodes the file to the end of its last compressed block — that is where it ends — and reads the checksum from the descriptor that follows.
• Its check: the decoded file must match its CRC-32 and its stated size. Only then is it intact.
• What is not the archive’s: a ZIP stored inside the archive has headers of its own; they are recognised as part of their file and left inside it, and an older copy of a file that an update left behind is listed apart and not selected.

What intact, partly recovered and lost mean

• Intact: decoded to its end and matched its checksum — exactly the file that was put in. It goes into the new archive with its compressed bytes copied as they are.
• Partly recovered: the file was cut off or damaged part way. Everything before the damage is kept, and it goes into the new archive only if you choose, with “(partial)” in its name. A partial text, log or CSV file is often useful; a partial photo shows its top part; a partial program or document of most other kinds may not open.
• Lost: nothing of its data is in the file, or where its data lies cannot be found.
• Encrypted and Not checked: a password-protected file, or one compressed with a method this page does not decode (such as BZIP2 or LZMA), or one that decoded to its end but whose checksum was in the part of the archive that never arrived. They are copied into the new archive exactly as they are; one that decoded is given the checksum of what decoded, so other programs open it.

Split archives

An archive split into parts by WinZip or Info-ZIP (name.z01, name.z02 … and finally name.zip) numbers its parts as disks, and its directory, in the last part, gives each file’s place within its own part. Choose all the parts together: the page joins them in order and reads them as one archive. Parts made by 7-Zip or a file splitter (name.zip.001, name.zip.002 …) are plain pieces of one archive and are joined the same way. A missing part takes the files inside it with it, but every file in the other parts can still be found.

What the repair is measured against

The page’s automated tests build archives in code and break them the ways downloads, copies and disks break them: cut short in the middle of a file, written as a stream with the sizes in data descriptors and then cut short, with a damaged block inside one file, with the signature of one file’s header overwritten, behind a self-extracting program, split into two parts, holding another ZIP inside, encrypted, compressed with a method that is not decoded, and made of nothing but zero bytes. Every intact file must come back byte for byte; every partly recovered one must be exactly the start of the original; the rebuilt archive must open in another program’s reader and pass this page’s own check with nothing wrong.

No success rate is published for other people’s archives: what comes back depends only on how much of the archive reached the disk.

Limitations

• Only ZIP archives and the formats built on ZIP are read. RAR and 7z archives, and TAR and GZIP files, are not repaired here.
• Missing bytes cannot be recreated: a file whose data was not in the download, or was overwritten, stays lost or partial.
• Files compressed with Deflate64 are decoded; files compressed with BZIP2, LZMA, XZ, Zstandard or PPMd are copied into the new archive unchecked, and cannot be saved into a folder from here.
• Encrypted files are never decrypted or cracked. They are copied as they are and open in the new archive with their own password.
• A partly recovered file holds only what was before the damage; after damage inside a compressed file, its last part may hold some bytes that are not the original’s.
• App and add-on packages (APK, XPI) are signed over the whole file, so a rebuilt package has to be signed again before it installs.
• Saving into a folder works in Chrome and Edge on a computer; other browsers download the new archive instead. A web page cannot set a file’s date: files saved into a folder carry the date they are written, while the new ZIP keeps each file’s own date.

Privacy

The archive is read by your browser on your device, a few megabytes at a time; nothing from it is sent anywhere, and the page works offline once it has loaded.