"Unexpected end of archive"

The message you see is a strong hint about which tool and which format you are dealing with — worth decoding before you do anything else, because each one fails at a slightly different point.

• WinRAR — "Unexpected end of archive." The classic. WinRAR reached the end of the file while a block header or the archive-end marker still said there should be more. Applies to both .rar and the ZIPs WinRAR opens.
• 7-Zip — "Unexpected end of data" (sometimes "Unexpected end of archive"). 7-Zip distinguishes a clean truncation ("end of data") from a wrong signature ("is not archive") from a flipped byte ("Data error"). "End of data" specifically means the stream stopped mid-way — a truncation, not scrambling.
• Info-ZIP unzip — "cannot find zipfile directory … End-of-central-directory signature not found." unzip seeks backward from the tail looking for PK\x05\x06 and never finds it, so it can't even build its file list. The data may be fine; the index is gone.
• Windows Explorer — "The compressed (zipped) folder is invalid." The built-in extractor is the least specific of all. It's usually the same missing-EOCD story — see "Compressed folder is invalid" for that exact wording.
• macOS Archive Utility — "Error 2 – No such file or directory." Famously opaque: the "file" it can't find is the central directory record it expected at the end. Same truncation, uniquely unhelpful message.
• Python zipfile — BadZipFile: File is not a zip file, or an error on .read(). If the EOCD is missing, zipfile refuses to open at all; if only a late entry is truncated, it opens fine and fails only when you read that member.
• GNU tar / gzip — "Unexpected EOF in archive" / "unexpected end of file." A different structure entirely (no central index at all) — covered below.

If your wording is on this list, you almost certainly have a short file, not a scrambled one — and the recovery is the same regardless of which tool reported it.

Every archive format keeps a small critical structure that says "the archive is complete and here is where its contents are indexed." That structure lives at or near the tail of the file — which is precisely the region a truncation destroys first. Knowing which marker is missing tells you how much is salvageable.

• ZIP — End Of Central Directory (PK\x05\x06). A ZIP is a run of local entries (each starting PK\x03\x04), then a central directory of PK\x01\x02 records, then the 22-byte EOCD. The EOCD is the index. Large or 4 GB+ archives add a ZIP64 EOCD record (PK\x06\x06) and locator (PK\x06\x07) just before it. Lose the tail and you lose the index — but not the self-describing local entries.
• RAR 4 — end-of-archive block (HEAD_TYPE 0x7B). After the Rar!\x1A\x07\x00 signature, RAR4 stores independently-decodable blocks and finishes with a terminating block. Files before the cut still decode; a RAR authored with a recovery record can reconstruct missing blocks outright.
• RAR 5 — end-of-archive header (header type 5). Signature Rar!\x1A\x07\x01\x00, a redesigned header format, same idea: a dedicated end header that a truncation removes.
• 7z — Start Header points to an End Header at the tail. After the 37 7A BC AF 27 1C signature and two version bytes sits a 20-byte Start Header holding NextHeaderOffset, NextHeaderSize and a CRC — a pointer to the header database at the very end of the file. Truncate the file and that pointer aims past the last byte. Worse, .7z defaults to solid compression, chaining files into one stream, so a lost tail can break every file after the last complete block.

The pattern is universal: the metadata the extractor needs first is stored last, so it's the metadata a truncation kills first. That's why "unexpected end" is so common and why the data itself is usually still recoverable.

Tar is the odd one out, and worth its own note because the diagnosis differs. A .tar has no central index at all: it is a plain sequence of 512-byte records — one header block per file (the ustar header with name, size and a checksum), then the file's data padded up to the next 512-byte boundary. The archive is declared finished by two consecutive all-zero 512-byte blocks. If those trailing zero blocks never arrived, tar prints "Unexpected EOF in archive" even though every file that was fully written is perfectly extractable — tar just walks the records front to back, so it recovers everything up to the byte it ran out on.

A .tar.gz (or .tgz) wraps that tar stream in gzip. A gzip member is a 10-byte header (1F 8B 08 …), the deflate stream, and an 8-byte trailer holding a CRC-32 of the uncompressed data and the ISIZE (original size mod 2³²). Truncate it and gzip reports "unexpected end of file" — it decompresses correctly right up to the cut, then has no trailer to verify against. The salvage is the same principle as ZIP: decode forward as far as the intact bytes allow.

"Unexpected end" is the symptom. The cause decides your best move, and there are three:

• A browser download that stalled or was cancelled. If the archive came from a link and the transfer never finished (a lingering .crdownload/.part, a "Failed – Network error"), the mechanics of exactly which bytes survive are specific — see a ZIP download that was interrupted.
• A cloud file that looks complete but isn't. Drive, Dropbox and OneDrive can hand you an HTML error page renamed .zip, or a partial sync — a truncation that masquerades as corruption. To tell a short file apart from genuine bit-rot, see diagnosing a corrupt cloud archive.
• The source itself is short. If the original really is missing its tail, no tool can invent the absent bytes — but IntactFile still extracts everything written before the cut. Drop it above to salvage the intact entries.

In every case the salvage itself is identical and runs entirely in your tab: IntactFile ignores the missing end-marker, scans forward from the top of the file catching each intact entry, and decompresses what the surviving bytes allow — pure TypeScript, no archive utility installed, and you can watch the Network tab confirm that zero bytes of a private archive ever leave your machine.