EOCD: the End of Central Directory record
The EOCD (End Of Central Directory record) is the fixed-signature record that sits at the very tail of a ZIP archive, after the central directory. Its signature is the bytes 50 4B 05 06. The EOCD is the entry point a reader uses to make sense of the whole file: rather than scanning forward from the front, an extractor seeks to the end, finds the EOCD, reads the offset it stores, and jumps straight to the start of the central directory.
Because the EOCD lives at the end and points back into the file, it is also the most fragile part of an archive. A download that gets cut off one block short, or a copy that leaves a stray byte, can destroy the EOCD — and with it, the reader’s only reliable way to locate the entries. A great many "cannot open zip" / "end-of-central-directory signature not found" errors trace back to exactly this record being missing or unreachable.
What the EOCD contains
The EOCD is a small fixed structure (22 bytes minimum, before any trailing comment). After the four-byte signature 50 4B 05 06 it records: the number of "this" disk and the disk where the central directory begins (legacy multi-volume fields, both 0 for a normal single-file archive), the number of central-directory records on this disk, the total number of entries in the archive, the size of the central directory, the offset of the start of the central directory from the beginning of the file, and finally a variable-length archive comment (up to 65,535 bytes).
Two of those fields do the real work: the *size* and *offset* of the central directory. With them, the reader performs one absolute seek and begins reading central-directory records directly — each of which in turn carries the per-entry offset into the compressed data. The entry counts are useful for sanity-checking (the reader knows how many records to expect), and the comment field is purely informational.
Why readers scan from the end
The EOCD has no fixed position measured from the start of the file, because the archive comment that trails it has variable length. So a reader cannot read an offset and jump to it. Instead it seeks to the end of the file and scans backwards for the signature 50 4B 05 06. Because the comment is capped at 65,535 bytes, the reader only ever needs to inspect the last roughly 64 KB + 22 bytes of the file. Once the signature is found, the rest of the record is read at a known offset relative to it.
This backward scan is why a small amount of trailing garbage usually does no harm (the reader skips past it) but a truncated file is catastrophic: if the last ~22 bytes were never written, the signature simply is not there. The scan fails, and the extractor reports that it could not find the End of Central Directory signature.
The ZIP64 hand-off
The classic EOCD fields for entry count, central-directory size, and central-directory offset are all 16- or 32-bit. When an archive grows past the classic limits — more than 65,535 entries, or a central directory beyond 4 GB — those fields are set to their maximum values (0xFFFF for the 16-bit count, 0xFFFFFFFF for the 32-bit size/offset) as a sentinel. That sentinel tells a conformant reader: "the real numbers are 64-bit — go read the ZIP64 extension records instead." A reader that ignores the sentinel will report absurdly wrong sizes or claim the archive is empty even though the data is intact.
Common "cannot open zip" causes
When an extractor prints "End-of-central-directory signature not found" or "Cannot find EOCD," the archive almost always failed to reach you whole. The usual causes:
- Truncated download or copy — the transfer stopped before the last bytes arrived, so the EOCD was never written. Re-downloading fixes it; it is not a bug in the extractor.
- A ZIP64 archive read by a non-ZIP64 tool — the classic EOCD looks plausible but its count fields are saturated sentinels, and an old reader trusts the wrong numbers.
- A trailing comment larger than 64 KB or a file concatenated onto the archive — the backward scan lands on a wrong signature, or the real EOCD sits beyond the scan window.
- Corruption near the tail — a single flipped bit inside the EOCD can point the central-directory offset into the middle of compressed data, producing a cascade of nonsense entries.
Frequently asked questions
What is the EOCD in a ZIP file?
The EOCD (End Of Central Directory record) is the trailing record, signature 50 4B 05 06, that marks the end of a ZIP archive and stores the size and offset of the central directory. A reader locates it by scanning backwards from the end of the file, then uses its offset to jump directly to the central directory rather than reading the file from the front.
Why does my ZIP say "end of central directory signature not found"?
That error means the extractor scanned the end of the file and never found the EOCD signature 50 4B 05 06. The most common cause is a truncated download or copy that cut off the last bytes before the EOCD was written. Re-downloading or re-copying the archive typically resolves it; the data before the cut may still be present but the file is structurally incomplete.
Where is the EOCD located?
At the very end of the archive, after the central directory and any trailing archive comment. Because the comment length is variable, the EOCD has no fixed byte offset from the start, so readers search backwards for its signature within roughly the last 64 KB + 22 bytes of the file (the maximum size of the comment plus the fixed record).
What is the EOCD signature?
The four bytes 50 4B 05 06. Every record type in the ZIP format carries its own signature, and 50 4B 05 06 uniquely identifies the End of Central Directory record. The local file header uses 50 4B 03 04, the central-directory record uses 50 4B 01 02, and the data descriptor uses 50 4B 07 08.
What happens to the EOCD in a ZIP64 archive?
The classic EOCD record is still present, but its entry-count, central-directory-size, and central-directory-offset fields are set to their maximum values (0xFFFF and 0xFFFFFFFF) as sentinels. Those sentinels tell a conformant reader to follow the ZIP64 extension records, which hold the real 64-bit values. A reader that ignores the sentinels will misread a large archive.