Fix it now
- Drop the file
- Repair runs locally
- Download the result
Google Drive's “Download folder” and Dropbox's “Download as .zip” both fail the same way when the connection drops: you are left with a ZIP that no tool will open. The reason is almost always mundane — the file is truncated, missing the index at its tail — not that its contents are scrambled. Drop the archive above and the tool reads its real structure in your browser, finds the entries that were fully written before the transfer stopped, and extracts those instead of refusing the whole file. Nothing is uploaded.
Truncation vs bit-rot: two different failures, one label
Two completely different problems both get called “corrupt archive,” and the fix depends on which one you have. Truncation means the file is short: the download stopped before the last byte arrived, so the archive is missing its tail. Bit-rot — here, a byte error introduced in transit — means the file is the right length but some bytes are wrong: a flipped or zeroed block somewhere in the middle. Telling them apart takes ten seconds and decides everything about what you can get back.
Check the size first. Google Drive and Dropbox both show the real byte count in the file's details pane; compare it to the copy on your disk. If yours is smaller, it is truncated — full stop. A truncated ZIP has lost its End Of Central Directory record — the PK\x05\x06 signature that lives in the last 22-plus bytes of the file — so an extractor that seeks to the end to read the index finds garbage or nothing. That is why unzip says End-of-central-directory signature not found or cannot find zipfile directory, 7-Zip and WinRAR say “Unexpected end of archive,” and Windows' built-in extractor says “The Compressed (zipped) Folder is invalid.”
If the size matches but extraction still fails, you have bit-rot. The index is present, so the tool gets into the archive and fails per-file instead: 7-Zip reports “Data error” or “CRC failed,” and unzip -t prints bad CRC against the specific entries. Every ZIP entry stores a CRC-32 of its uncompressed data in both its local header and the central directory; when the decompressed bytes do not hash to that value, the tool knows that one file is damaged — but the others usually are not.
Why a cloud download corrupts an archive in the first place
Interrupted transfers truncate archives more than anything else, and cloud storage adds its own twists. When you use Drive's “Download folder” or Dropbox's “Download as .zip,” the server builds the ZIP on the fly and streams it to you. Because it is compressing while sending, it does not know each file's size or CRC in advance, so it sets general-purpose bit 3 in every entry and writes the CRC and sizes after the compressed data, in a data descriptor (PK\x07\x08). If the connection drops mid-stream you get a clean prefix of a valid ZIP with no central directory at all — textbook truncation.
Large folders make it worse because they cross the ZIP64 threshold: more than 65,535 files or 4 GiB of data. A ZIP64 archive keeps a PK\x06\x06 ZIP64 EOCD record and a PK\x06\x07 locator at the very end — even more tail metadata to lose when the transfer stops early.
Two cloud-specific traps masquerade as corruption. First, Google Drive refuses to virus-scan large files and serves an HTML interstitial instead of the bytes; if you fetched the link with wget, curl or a script, your “.zip” may actually begin with <!DOCTYPE html> rather than PK\x03\x04 — it is a web page, not an archive. Second, segmented download managers that grab a file in parallel byte-ranges can leave a gap or a duplicated block when one range fails silently, producing a full-length file with a corrupt middle: bit-rot, not truncation. Opening the file in a hex viewer and checking whether the first four bytes read 50 4B 03 04 (PK\x03\x04) tells you immediately whether you even have a ZIP.
What the salvage actually extracts
Drop the file above and the tool ignores the missing or unreadable index and scans forward from the top, catching every PK\x03\x04 local file header and decompressing the deflate stream that follows while the bytes last. For a truncated archive, every entry that was completely written before the cut comes back intact; only the one file straddling the truncation point is partial or lost. For bit-rot, the entries whose CRC-32 still checks out extract normally, and the tool flags the specific entry whose hash fails rather than condemning the whole archive. This is pure TypeScript running in your tab — no unzip binary, nothing transmitted.
RAR and 7z follow the same principle over different structures. A RAR (signature Rar!\x1a\x07\x00 for v4, Rar!\x1a\x07\x01\x00 for v5) stores files in independent blocks, so the ones before the damage still decode, and a RAR authored with a recovery record repairs far better because that record exists precisely to rebuild missing blocks. A .7z (signature 7z\xBC\xAF\x27\x1C) is the fragile case: it keeps its header database at the tail and usually uses solid compression that chains many files into one stream, so a lost tail or a mid-stream byte error can break decompression for everything after the last intact block. The tool salvages what the surviving blocks allow and says so plainly when a solid stream cannot be continued.
The honest limit: missing bytes stay missing
Nothing can recover bytes that never reached your disk. If the download stopped at 70%, the final 30% of the compressed data simply does not exist locally, and no tool — not this one, not WinRAR's own Repair, not a paid recovery suite — can invent it. The real fix for truncation is to re-download from Drive or Dropbox, ideally avoiding a server-zipped folder: pull the original file directly, or the folder in smaller batches, so the transfer is more likely to finish.
Bit-rot inside a compressed stream is just as unforgiving at the level of the one damaged file. Deflate is a stateful stream — a single flipped bit derails the Huffman/LZ77 decoding from that point on — so the affected entry usually comes back truncated at the error, even though its CRC-32 told you exactly which file was hit. Encrypted archives (AES-256 ZIP, RAR or 7z password protection) cannot be scanned without the password, because the entries are ciphertext. What the salvage reliably prevents is a partly-arrived archive becoming a total loss: if nine of ten files landed, there is no reason to lose the nine while chasing the tenth. And because everything runs locally, an archive of financial records, source code or personal documents is never copied to an unknown server just to look inside — open the Network tab and confirm zero bytes leave.
What this can and can't fix
Can fix
- A ZIP truncated by an interrupted Drive/Dropbox download — entries written before the cut are recovered by scanning PK\x03\x04 local headers
- Bit-rot in one entry: files whose CRC-32 still verifies extract normally, and the damaged entry is flagged instead of failing the whole archive
- Server-zipped folders that stream data descriptors (PK\x07\x08) and lost their central directory to a dropped connection
- ZIP64 folder downloads (over 65,535 files or 4 GiB) missing the PK\x06\x06 record and PK\x06\x07 locator at the tail
- RAR archives where blocks before the damage still decode — dramatically better with a recovery record
- 7z archives up to the last complete (solid) compression block that survived
Can't fix
- Any file whose compressed data sat after the truncation point — those bytes never reached your disk (re-download instead)
- A '.zip' that is really Google Drive's virus-scan HTML page — it is a web page, not an archive
- The single entry hit by a mid-stream byte error, past the point where its deflate stream broke
- A 7z solid stream past its last intact block (later files in the chain cannot be decompressed)
- Encrypted / password-protected archives without the password (the entries are ciphertext)
If a repair fails, we tell you why (missing data versus broken structure), and you are never charged for a failed repair.