ZIP from an interrupted download

A ZIP is written front-to-back but read back-to-front. Every file you added is stored as a local file entry — a header beginning with the signature PK\x03\x04, carrying the name, the compression method (0 = stored, 8 = deflate), and then the compressed bytes — but the authoritative index of where those entries live is the central directory (PK\x01\x02 records) written last, immediately before the 22-byte End Of Central Directory record, PK\x05\x06. An extractor opens the file by seeking to the end and scanning backward for that PK\x05\x06 signature — up to roughly 65,557 bytes back, because the record ends with a variable-length comment field. Only after it finds the EOCD does it know how many entries the archive holds and where each central-directory record begins.

Now picture the download that stopped at 70%. The bytes that never arrived are the ones written last: the central directory and the EOCD. The extractor seeks to the end, scans backward, never sees PK\x05\x06, and gives up before touching a single file. That is the exact source of unzip's "End-of-central-directory signature not found", 7-Zip's and WinRAR's "Unexpected end of archive", Explorer's "The Compressed (zipped) Folder is invalid", and macOS Archive Utility's "Unable to expand … (Error 2)". None of them mean the stored files are scrambled — they mean the table of contents at the tail is gone.

Interrupted downloads are especially prone to this because of how many ZIPs are generated. An archive assembled on the fly by a server — a "download all" from cloud storage, a GitHub source tarball's ZIP sibling, an export bundle — is usually streamed: general-purpose bit-flag bit 3 (0x0008) is set, the compressed size and CRC-32 in each local header are left as zero, and the real values are appended after the entry's data in a data descriptor (PK\x07\x08). For those archives the central directory is the only place the sizes are guaranteed, so losing the tail is doubly damaging to a normal extractor. The half-written file your browser left behind — a Chrome/Edge .crdownload, a Firefox .part, or a .zip that is simply shorter than the response's Content-Length — still carries every complete entry up to the cut and nothing after it.

The salvage does not need the missing index at all, because in a ZIP every local entry is self-describing. Instead of seeking to the end, the tool scans forward from offset 0, stopping at each PK\x03\x04 local header it finds, reading the file name and compression method, and then decompressing the deflate stream that follows. Deflate is self-terminating: a stream is a sequence of blocks and the final block carries a BFINAL bit set to 1, so the decoder can find where an entry's data ends even when the local header's size field was left at zero by a streamed writer. When the stream terminates cleanly the tool records a recovered file, skips any trailing PK\x07\x08 data descriptor, and continues to the next PK\x03\x04. This runs as plain TypeScript in your tab — no unzip binary, nothing transmitted.

The result is that every file fully written before the interruption comes back, in order, with its original name and directory path. If the download died in the middle of the fourth of ten files, you get the first three intact and a fourth that is partial or dropped; the six that never arrived cannot be conjured, but they were never the point. A "stored" entry (method 0, no compression — common for already-compressed contents such as JPEGs or MP4s placed inside the ZIP) is even simpler to salvage: its bytes are copied verbatim up to the truncation point, so even a half-arrived large file frequently yields a usable leading fragment rather than nothing at all.

No tool can return bytes that never reached your disk. If the connection dropped at 70%, the final 30% of the compressed data does not exist locally, and nothing — not this page, not WinRAR's "Repair", not a paid recovery suite — can reconstruct it. The one real fix for the missing tail is to download the archive again from the source, ideally with a client that supports HTTP range requests so an interrupted transfer can resume where it stopped instead of restarting. If the server sent an ETag or a Content-Length, comparing that length against the size of your partial file tells you exactly how much is actually missing.

A few honest edges. A ZIP that is encrypted (a password set at zip time, general-purpose bit 0) cannot be scanned without the password, because the entry data is ciphertext with no deflate structure to follow. A very large archive written in ZIP64 format keeps its own trailing structures — the ZIP64 EOCD record (PK\x06\x06) and its locator (PK\x06\x07) — which are lost with the tail exactly like the classic EOCD, but the forward scan still recovers the local entries regardless of format. And a download so short that only a fragment of the very first local header arrived has nothing to walk. Everything between those extremes is fair game.

Because the whole operation happens in your browser, the archive is never copied to a server just to look inside it — which matters when a "download all" bundle holds tax documents, exported chat histories, or private source code. You can open the Network tab, run the recovery, and confirm that 0 bytes of the file ever leave your machine.