"Unexpected end of archive"

A ZIP file is not one continuous blob — it is a series of local file entries followed by a central directory at the very end. Each entry begins with the signature PK\x03\x04, carries its own name, compression method and size, then the deflated data. After the last entry comes the central directory (PK\x01\x02 records), and the file finishes with the End Of Central Directory record, PK\x05\x06. That EOCD is the index: it tells the extractor how many files exist and where each one starts.

Here is the catch. The index lives at the very end of the file. When a download or copy is cut short, the tail is exactly what goes missing — so the extractor seeks to where the EOCD should be, finds data (or nothing) instead of the PK\x05\x06 signature, and reports "Unexpected end of archive." The archive is not scrambled; it is simply missing its table of contents, and possibly the last file or two.

RAR and 7z fail the same way for the same reason. A RAR keeps block headers and, at the end, an archive-end marker; a .7z keeps its header database at the tail of the file and typically compresses many files together into one solid stream. In every case the metadata the tool needs first is the metadata a truncation destroys first.

Because each ZIP entry is self-describing, the whole central directory is redundant for extraction — it is an index, not the data. The tool ignores the missing EOCD and instead scans forward from the top of the file, catching every PK\x03\x04 local header it can find and decompressing the deflate stream that follows while the bytes hold out. Any file that was completely written before the cut comes back intact; the one file that straddled the truncation point may come back partial or not at all. This runs as pure TypeScript in your tab — no archive utility installed, nothing sent anywhere.

RAR and 7z are more constrained but not hopeless. In a RAR the files stored before the truncation still decode, and a RAR authored with a recovery record repairs dramatically better because that record is designed to reconstruct missing blocks. A .7z is the fragile case: with no recovery record and solid compression chaining files together, losing the tail can break decompression for everything after the last complete block. The tool salvages what the surviving blocks allow and is honest when a solid stream can't be continued.

No software can recover data that was never in the file. If the download stopped at 60%, the last 40% of the compressed data does not exist on your disk, and nothing — not this tool, not WinRAR's own repair, not a paid recovery suite — can invent it back. The fix for that is to re-download or re-copy the archive from the source so you have the complete bytes.

What we can reliably do is stop a partially-arrived archive from being a total loss. If nine of ten files landed before the connection dropped, there is no reason to lose the nine while chasing the tenth. And because the whole operation happens in your browser, an archive that might contain financial records, source code, or personal documents is never copied onto an unknown server just to peek inside it — you can watch the Network tab and confirm zero bytes leave.