A zip file is not one solid block. It is a sequence of parts, each with a specific job. The zip file structure has three main sections: local file headers with their data, a central directory, and an end of central directory record. When a zip file gets damaged, the files themselves often survive because each file is compressed independently. The problem is the directory that tells tools where everything sits gets broken. Understand the layout and you will see why a repair can bring the files back.
The Three Part Layout of a ZIP File
Every zip file follows the same order. First come the local file headers. Each header is followed by the compressed or stored data of that file. After all the files, the central directory lists every file again with its location, name, and other details. The end of central directory record (EOCD) sits at the very end. It tells an unzip tool where to find the central directory. This is the zip file format explained in its simplest form. Damage to the end of the file, where the EOCD lives, stops most tools from opening the archive at all.
Local File Headers Where Each File Starts
Signature And What It Stores
Each file in a zip archive begins with a zip local file header. Its signature is 50 4B 03 04. The letters PK in every signature are the initials of Phil Katz, creator of PKZIP. This header stores the file name, the compression method used, the CRC-32 checksum of the uncompressed data, and the sizes of both the compressed and uncompressed data. The most common compression methods are 0 (stored, no compression) and 8 (Deflate).
Why Independent Compression Matters
Because each file is compressed independently, damage to one header or its data does not affect the other files. The CRC-32 checksum in each header lets you detect if that file's contents are damaged.
The Central Directory the Archive's Table of Contents
After all the file data, the zip central directory begins. Each entry in the central directory has a signature of 50 4B 01 02. These entries duplicate the file names, compression methods, and sizes from the local headers. They also store the offset where the local header for that file starts in the archive. Unzip tools read the EOCD first, then jump to the central directory, and finally use those offsets to read each file. Because local headers duplicate the file names and sizes, a repair can rebuild the central directory by scanning them.
The End of Central Directory Record the Starting Point
The end of central directory record (EOCD) is the last part of the zip file. Its signature is 50 4B 05 06. The EOCD is at least 22 bytes long and may be followed by a comment up to 65,535 bytes long. This small record holds the offset and size of the central directory. An unzip tool reads the EOCD first. Then it jumps to the central directory. That is why damage at the end of the file stops most tools. If the EOCD is missing or corrupted, the tool cannot find the central directory, so it refuses to open the archive.
Why Damage at the End Breaks Opening
When a zip file is truncated or the end is overwritten, the EOCD is lost. Without it, normal unzip tools do not know where the central directory starts. The central directory might still be intact, but the tool cannot locate it. The local headers and their data remain in the file. The tool has no map. This is the most common reason a zip file fails to open even though the files inside are fine. A repair tool that scans for local headers can rebuild the directory information from scratch.
How Repair Tools Rebuild the Central Directory
Scan And Reconstruct
A repair works by ignoring the broken EOCD and central directory. Instead, it scans the file from the beginning looking for the zip signature pk of local file headers (50 4B 03 04). For each header found, it reads the file name, compression method, and sizes. It then extracts the compressed data and verifies it with the CRC-32 checksum. Once all files are located, the repair tool writes a new central directory and a new EOCD. The result is a working zip file. The steps are:
- Scan the damaged file for local header signatures.
- Read each file's name, compression method, and sizes from the header.
- Copy the compressed data that follows each header.
- Calculate the CRC-32 checksum to confirm the data is intact.
- Write a new central directory entry for each file.
- Write a new EOCD at the end.
What Survives and What Does Not
If only the end of the archive is damaged, the files themselves usually survive. Each file is compressed independently, so damage to one file does not spread to others. The CRC-32 checksum stored in each local header lets you verify that file. However, if a local header itself is corrupted, that specific file may be unrecoverable because the header contains the file name and compression method needed to extract it. The other files in the archive can still be recovered. Use a tool like zip.repair to rebuild a working archive from the surviving local headers.