ZIP Central Directory
The zip central directory is the master index of a ZIP archive: a contiguous table of contents at the end of the file that lists every entry with its name, byte offsets, compressed and uncompressed sizes, timestamps, compression method, and a CRC32 checksum. A reader consults it first to enumerate an archive's contents without touching the compressed data.
This end-of-file placement separates ZIP from many other archive formats. Each entry's payload is preceded by its own local file header, but the authoritative metadata for the whole archive lives in the central directory at the back, followed by the End of Central Directory (EOCD) record.
How a ZIP file is laid out
A ZIP file is a sequence of three logical regions. First come the local file entries, each a local file header plus that file's compressed data. After all entries comes the central directory: one central file header per entry, concatenated. Finally, the very last structure is the End of Central Directory (EOCD) record (sometimes written EOCDR).
The layout is: [local header 1 + data 1] [local header 2 + data 2] ... [central directory entry 1] [central directory entry 2] ... [EOCD]. The EOCD is the entry point: it records the total entry count and the byte offset where the central directory begins, so a reader can jump straight to the index.
- Local file header + compressed data (repeated per entry)
- Central directory file headers (one per entry, the master index)
- End of Central Directory (EOCD) record (the final, terminating structure)
The End of Central Directory (EOCD) record
The EOCD is a fixed 22-byte record (plus an optional trailing comment up to 65,535 bytes) that marks the end of the archive. It begins with the 4-byte signature 0x06054b50 (the bytes 50 4B 05 06, or PK\x05\x06). Its fields include the total number of central directory entries, the size of the central directory in bytes, and the 32-bit offset to the start of the central directory.
Because the EOCD sits at the very end, a reader finds it by seeking near the end of the file and scanning backward for that signature. It must validate the surrounding fields rather than trusting the magic bytes alone, since the same 4-byte sequence can legitimately appear inside compressed data or in the archive comment.
Why listing a zip is instant
This backward index design is why enumerating even a multi-gigabyte archive is effectively instantaneous. The reader seeks to the end, reads the small EOCD record, then reads the central directory at the offset it points to. It never has to scan, parse, or decompress the bulk of the file just to list its contents; the cost depends on the number of entries, not the total compressed size.
The duplicate metadata in each local file header is what makes this possible: the central directory holds the authoritative copy, so the reader can ignore the local headers until it actually extracts an entry. This is exactly how client-side readers like ZipTool parse an archive in the browser without uploading it.
"End of central directory signature not found"
This is the single most common ZIP error, and it means what it says: the reader scanned backward from the end and could not locate an EOCD with the 0x06054b50 signature. With no EOCD there is no pointer to the central directory, so the reader has no index and refuses to treat the file as a valid ZIP.
The usual causes are: the file was truncated or only partially downloaded (the tail, where the EOCD lives, is missing); the archive is corrupted; the file is not actually a ZIP despite a .zip extension (a .gz, .tar.gz, or .7z will trigger this); or the archive uses features the reader does not support. Re-downloading or verifying the file type resolves most cases.
ZIP64: past the 4 GB and 65535-entry limits
The classic ZIP format encodes sizes and offsets as 32-bit values and entry counts as 16-bit values. That caps an individual entry and the archive's overall size at 4 GB (2^32 - 1 bytes) and the number of entries at 65,535 (2^16 - 1). ZIP64 lifts these limits with 64-bit (8-byte) fields.
When a standard field would overflow, the writer stores the sentinel 0xFFFFFFFF (for sizes/offsets) or 0xFFFF (for counts) in the regular field and records the true value in a ZIP64 extended-information block. A ZIP64 archive adds a ZIP64 EOCD locator and a ZIP64 EOCD record between the central directory and the conventional EOCD, pointing to a 64-bit central directory. Most modern tools read and write ZIP64 transparently, but an older or incomplete reader can fail on large archives.
Frequently asked questions
What is the ZIP central directory?
It is the master index of a ZIP archive, stored at the end of the file. It contains one record per entry holding the entry's name, offsets into the file, compressed and uncompressed sizes, modification timestamp, compression method, and CRC32 checksum. A reader reads it first to enumerate and locate every entry without decompressing anything.
What does "end of central directory signature not found" mean?
It means the reader searched backward from the end of the file and could not find the EOCD record's 4-byte signature (0x06054b50). Without the EOCD it has no pointer to the central directory and treats the file as not-a-ZIP. The file is usually truncated, only partially downloaded, corrupted, or not actually a ZIP (for example a .gz or .7z with a .zip extension).
Why is listing a zip so fast?
Because the central directory sits at the end of the file and the EOCD points directly to it. The reader seeks to the end, reads the small EOCD, then reads the central directory at the offset it specifies. It never scans or decompresses the bulk of the data, so the time depends on the number of entries, not the archive's total size.
What is ZIP64?
ZIP64 is the extension that overcomes the original format's limits: 4 GB (2^32 - 1 bytes) for file sizes and offsets, and 65,535 (2^16 - 1) for the number of entries. When a field would overflow, ZIP64 stores a sentinel value in the standard field and the real 64-bit value in an extended-information block, and adds a ZIP64 EOCD locator and EOCD record before the conventional end-of-archive record.