ZIP64: lifting the 4 GB and 65,535-entry limits
ZIP64 is the set of extensions that lifts the classic ZIP format’s two hard size limits. The original format stores entry counts in 16-bit fields and sizes and offsets in 32-bit fields, which caps a single archive at 65,535 entries and any single value at 4 GB (2³² bytes). ZIP64 introduces 64-bit fields to hold the true values when those limits are exceeded, while keeping the archive readable by older tools in the common case.
The trick is a sentinel hand-off: when a value would overflow the classic field, the writer sets the classic field to its maximum (0xFFFF or 0xFFFFFFFF) and records the real 64-bit value in a separate ZIP64 field. A conformant reader checks for the sentinel and, if present, reads the 64-bit value instead. A reader that skips that check happily reports a "4 GB" file or an empty entry list on an archive that is actually fine.
The classic limits ZIP64 fixes
The classic ZIP format, designed for floppy-disk and early hard-drive scale, reserved parsimonious field widths. The number of entries per archive is a 16-bit value, so an archive can hold at most 65,535 entries. Each entry’s compressed size, uncompressed size, and the offset of its local file header are 32-bit values, so no single entry can exceed 4 GB, and no entry can begin beyond the 4 GB mark in the archive. The archive-wide size and central-directory offset in the EOCD are likewise 32-bit.
For decades these limits were enormous. They stopped being enormous once databases, virtual-machine images, backups, and container layers routinely produced multi-gigabyte files. ZIP64 is the backwards-compatible answer: it does not change the format for normal archives, it only activates when a value genuinely would not fit.
How the sentinel hand-off works
Three records participate. In each central directory entry, the 32-bit size/offset fields may be set to 0xFFFFFFFF; the real values then live in the entry’s "extra field" under a ZIP64 extra-field tag. At the end of the file, alongside the EOCD, ZIP64 adds two more structures: the ZIP64 EOCD record (which mirrors the classic EOCD but with 64-bit fields) and the ZIP64 EOCD locator (signature 50 4B 06 07), a short pointer that tells the reader where the ZIP64 EOCD record is.
The reading order is therefore: scan backwards for the classic EOCD as usual; inspect its entry-count and offset fields; if any are at the maximum sentinel value, read the ZIP64 EOCD locator (which sits just before the classic EOCD), follow it to the ZIP64 EOCD record, and take the real 64-bit counts and offsets from there. Only then can the reader walk the central directory correctly for a large archive.
What goes wrong when a reader ignores ZIP64
A reader that treats the classic fields as always-accurate will, on a ZIP64 archive, see the sentinels as literal values. It may report that an archive contains exactly 65,535 entries when it contains far more, or that a file is exactly 4 GB when it is 40 GB, or refuse to open entries whose offsets read as 4 GB into the file. The data is intact and the archive is valid — the tool simply never followed the hand-off.
This is why "my tool shows the wrong size but the file is fine" on very large archives is so often a ZIP64-read defect rather than corruption. Modern libraries handle it; very old or minimal ones sometimes do not. The same backwards-compatible design that keeps old tools from crashing on small archives is what allows them to silently misread large ones.
ZIP64 in practice
Most archive tools create ZIP64 archives only when forced to — when an entry exceeds 4 GB or the entry count exceeds 65,535 — because some very old unzip tools still mishandle ZIP64 extensions even on small archives. For that reason a "store as ZIP64 always" setting exists in some tools but is not the default. In a fully client-side viewer like ZipTool, ZIP64 support is handled by the parsing library: the EOCD and central directory are read once in your browser, and ZIP64 sentinels are followed automatically so large archives display their real sizes and full entry lists.
Frequently asked questions
What is ZIP64?
ZIP64 is the set of ZIP format extensions that replaces the classic 16-bit entry-count and 32-bit size/offset fields with 64-bit values, lifting the 65,535-entry and 4 GB-per-value limits. It activates only when a value would overflow, using maximum-value sentinels (0xFFFF and 0xFFFFFFFF) that point a reader to 64-bit fields stored in extra fields and a ZIP64 End Of Central Directory record.
What is the maximum ZIP file size?
With ZIP64 extensions, the practical maximum is in the exabyte range — 64-bit fields for sizes and offsets, well beyond any real archive. Without ZIP64, the classic format caps a single entry and the central-directory offset at 4 GB, and the entry count at 65,535. Real-world limits come from the filesystem and the tool, not the format.
How many files can a ZIP contain?
The classic 16-bit entry-count field limits a ZIP to 65,535 entries. ZIP64 lifts this with a 64-bit count, so the limit becomes effectively unreachable. Archives with hundreds of thousands or millions of small entries require ZIP64 and a reader that follows its sentinels.
Why does my archive report exactly 4 GB or 65,535 entries when it is larger?
Those are the sentinel values the classic ZIP fields use to signal that the real value overflows into ZIP64. If your tool shows them literally — a 4 GB size or a 65,535 entry count on an archive that is clearly larger — the tool is not following the ZIP64 hand-off. The archive is valid; use a tool that supports ZIP64 extensions.
Do all unzip tools support ZIP64?
Modern ones do, but some very old or minimal implementations do not follow the sentinel hand-off and will misread large ZIP64 archives — reporting wrong sizes or truncated entry lists even though the data is intact. Because of this, most archive tools only emit ZIP64 extensions when an entry actually exceeds 4 GB or the count exceeds 65,535, rather than always.