When a Google Takeout ZIP won’t open
A download that stopped early, a split export, or a .tgz ·
This comes out of making Mailward read Takeout ZIPs directly. Its failure telemetry records a category such as “ZIP, 100 MB–1 GB, could not be read” and never anything from the file; on 11 October 2026 it showed one visitor fail on a ZIP and open one in the same size range eight minutes later. The likeliest explanation is a download that had not finished yet, and testing that idea produced the measurements below.
The short answer
A common reason is that the ZIP is not damaged but incomplete. A ZIP keeps its list of contents at the very end of the file, so a download that stops early leaves a file every tool calls invalid. Test the archive before you extract it, and if the test fails, download that archive again. Google’s own advice for an archive that does not work is to create another one, or to export fewer products at a time.
unzip -t takeout-20261012T000000Z-001.zip
# → No errors detected in compressed data of …
python3 -m zipfile -t takeout-20261012T000000Z-001.zip
# → Done testing (exit status 0)
unzip -l takeout-20261012T000000Z-001.zip | grep Takeout/Mail/
# lists the mailbox without extracting anythingWhat Takeout hands you
According to Google’s Takeout help page (read on 12 October 2026), you pick a file type — zip files or tgz files — and a maximum archive size; “if the data you’re downloading is larger than this size, multiple archives will be created”, and Google suggests the 50 GB limit to make a split less likely. Takeout puts a file named archive_browser.html in the archive that describes what is inside. Gmail arrives as one MBOX file under Takeout/Mail/ — for a whole mailbox, All mail Including Spam and Trash.mbox — with each message’s labels in an X-Gmail-Labels header. Google also recommends downloading Takeout exports on a desktop computer rather than a phone; more on that below.
What “invalid” usually means: the end never arrived
Every ZIP ends with an end-of-central-directory record — 22 bytes, plus an optional comment of up to 65,535 bytes — that points back to the central directory, the list of every file in the archive. A reader looks for that record in the last 65,557 bytes of the file. Stop a download early and the record is gone, and with it the list.
To see what that does in practice, we built a Takeout-shaped ZIP — 400 invented messages in Takeout/Mail/All mail Including Spam and Trash.mbox, 2.6 MB unpacked and 1.4 MB zipped — and kept its first half (686,995 bytes), which is what an interrupted download leaves on disk. Then we asked each tool to extract it.
| Tool | What it left on disk | Exit status | What it said |
|---|---|---|---|
| unzip (Info-ZIP 6.00, as shipped with macOS) | Nothing | 9 | End-of-central-directory signature not found. |
| tar, i.e. bsdtar (macOS; libarchive) | The mailbox at its full 2,593,761 bytes — 1,297,405 of them zero bytes — holding 200 of the 400 messages | 1 | Takeout/Mail/All mail Including Spam and Trash.mbox: ZIP decompression failed (-5): Unknown error: -1 |
| Python 3 zipfile | Nothing | 1 | zipfile.BadZipFile: File is not a zip file |
| ditto -x -k (macOS) | Nothing | 1 | ditto: Couldn't read pkzip signature. |
3 of the 4 refuse outright, which is the useful outcome. The other one is the one to watch. tar on a Mac is bsdtar, and it reads a ZIP from the front, trusting the size each file declares in its own header rather than the list at the end. So it wrote the mailbox at the size the archive promised, filled what never arrived with zero bytes, and exited with status 1 — an error that is easy to miss in a terminal, next to a file whose size looks exactly right. Any mail program shows that file as the first half of the mail and nothing after it. If you extract with tar, check the exit status, or test the ZIP first.
Mailward refuses such a file before reading anything from it, with the message “This ZIP is incomplete: it starts like a ZIP but stops before the index every ZIP ends with, which is what a download or copy that did not finish leaves behind” and the file’s size, so it can be compared with the expected one.
Check before you extract
Both tests above read the whole archive and verify it, and both fail on a cut one: on our half-file, unzip -t stopped with exit status 9 and “End-of-central-directory signature not found.”, and python3 -m zipfile -t with exit status 1 and “zipfile.BadZipFile: File is not a zip file”. On the complete archive they printed “No errors detected in compressed data of full.zip.” and “Done testing”. Python’s version works anywhere Python 3 is installed, Windows included.
Split exports: several archives, one mailbox
When the export is larger than the size you chose, each part is its own archive with its own list of contents, so each one is tested, listed and extracted on its own. To find the part that holds your mail, list each without extracting it and look for Takeout/Mail/ — the last command in the box above does that.
Over 4 GB: ZIP64
The original ZIP fields are 32 bits wide, so sizes and offsets stop at 4 GiB. A larger archive carries ZIP64 records instead, and its classic end record holds 0xFFFFFFFF where the offset would be. A tool without ZIP64 support reports such an archive as damaged. We rebuilt the same archive with ZIP64 records forced (zip -fz): its end record does hold 0xffffffff and a ZIP64 locator follows the directory, and unzip -t, Python, bsdtar and ditto all read it without complaint, as does Mailward’s reader.
ZIP or TGZ
Google’s help page warns that “special software may be required to unpack a tgz archive” and that such files can’t have Unicode characters in their names. A .tgz is a gzip stream (its first two bytes are 1F 8B) around a tar archive (the text ustar at byte 257). Mailward does not read either one; it recognises both by those bytes and says to extract the archive first — including the halfway case, a .tgz that was gunzipped but never untarred.
On a phone
Google’s recommendation to download on a desktop computer matches what our telemetry shows. We have seen phones hand over ZIP files that no longer end in .zip, and an Android file picker can hand the browser a temporary copy of a file that is gone after the first read. Mailward Pro recognises a ZIP saved under another name by its content; a free visitor is told to give it the .zip extension, or to extract it.
Getting the mail out
- Extract, then open the .mbox in the MBOX viewer. It is read from disk in chunks, so there is no size limit; the whole file is listed and searched for free, and reading messages past the first 500 MB of a very large mailbox is part of the paid licence. Why that works for a multi-gigabyte Takeout export is in reading a multi-gigabyte MBOX in the browser.
- Or drop the ZIP itself (Pro). Only the mail files inside are unpacked, and everything read from a ZIP is held in memory, so the mail files may unpack to at most 1 GB; past that, extract the ZIP and open the .mbox directly.
- Neither recovers what never downloaded. A cut archive has to be downloaded again.
Measured
Single runs on 2026-10-12: macOS 27.0.1; UnZip 6.00 of 20 April 2009, by Info-ZIP, with modifications by Apple Inc.; bsdtar 3.5.3 - libarchive 3.7.4 zlib/1.2.12 liblzma/5.4.3 bz2lib/1.0.8; Python 3.14.8; archives written by Zip 3.0 (July 5th 2008), by Info-ZIP, with modifications by Apple Inc.. The archive is built by a script (scripts/bench/takeout-zip.py) from a seeded mailbox of invented messages on example.com addresses; part of every message is random base64, like an attachment, so the ZIP is 53% of the mailbox’s size rather than the small fraction plain text would shrink to. We did not test Windows File Explorer, 7-Zip or WinRAR, and make no claim about them.
More on the formats involved: the email archive formats reference, and a small public mailbox to try a reader with on the sample files page.