ZIP Archive

The Phil Katz Story

In 1988, Phillip Walter Katz faced a lawsuit from System Enhancement Associates (SEA), the company behind the popular ARC compression format. Katz had created PKARC, a faster and freely distributed tool compatible with SEA's format. SEA sued for trade secret misappropriation. The settlement cost PKWARE $22,500 in royalties plus $40,000 in legal expenses. Rather than continue working within someone else's format, Katz did something remarkable: he created an entirely new archive format from scratch and published the specification openly, declaring it would always be free for competing software to implement.

On February 14, 1989, PKZIP 1.0 shipped. The magic bytes at the start of every ZIP file — 50 4B in hexadecimal, the ASCII letters "PK" — are Phil Katz's initials, permanently encoded into every ZIP archive ever created. Katz was found dead in a hotel room on April 14, 2000, at age 37. His creation outlived him by decades and now underpins billions of files across every operating system on Earth.

Reading ZIP Files Backwards: The EOCD-First Model

ZIP has an architectural quirk that surprises most developers: the file is designed to be read from the end, not the beginning. A ZIP archive has three major sections:

1. Local file headers + compressed data — one pair per archived file, written sequentially
2. Central directory — a repeated set of entries mirroring the local headers, with full metadata and byte offsets pointing back to each local header
3. End of Central Directory Record (EOCD) — a single record at the very end that points to the central directory

A ZIP parser starts by seeking to the end of the file, scanning backward to locate the EOCD signature (50 4B 05 06), then reads the central directory offset from the EOCD, jumps to the central directory, and from there locates every file in the archive. This end-anchored design has three practical consequences. First, files can be appended to a ZIP without rewriting the archive — just add new local entries and write a new central directory and EOCD. Second, a ZIP can be embedded inside another file (such as a self-extracting EXE) because the parser ignores everything before the ZIP data and reads from the end. Third, if the EOCD is lost to truncation or corruption, the entire archive becomes unreadable even though all compressed file data may be intact.

DOCX, XLSX, EPUB, APK — They Are All ZIP Files

One of the least-known facts in computing: many common file formats are simply ZIP archives with specific internal directory structures. Rename a .docx file to .zip and unzip it — inside you will find XML files describing document content, styles, relationships, and embedded media. The same applies to:

• DOCX / XLSX / PPTX — Microsoft Office Open XML (OOXML), standardized as ECMA-376 and ISO/IEC 29500
• ODT / ODS / ODP — OpenDocument Format, standardized as ISO/IEC 26300
• EPUB — E-book container defined by the W3C
• JAR / WAR / EAR — Java archive formats
• APK — Android application packages
• XPI — Firefox browser extensions
• KMZ — Google Earth placemarks
• CBZ — Comic book archives

ISO 21320-1:2015 formalized this practice by defining a restricted ZIP profile for document containers. The ISO standard permits only Store (method 0) and DEFLATE (method 8) compression, forbids encryption, forbids multi-disk spanning, and normatively references APPNOTE version 6.3.3. Any file format that claims ISO 21320-1 conformance must be a valid ZIP file meeting these restrictions.

DEFLATE: The Algorithm Inside

DEFLATE, the default and overwhelmingly dominant compression method in ZIP files, combines LZ77 sliding-window matching with Huffman coding. The compressor scans input data for repeated byte sequences within a 32 KB window, replacing matches with back-references (distance, length pairs), then encodes the result using variable-length Huffman codes. DEFLATE is also the algorithm inside gzip, PNG, and HTTP content encoding — making it arguably the most widely deployed compression algorithm in history.

DEFLATE achieves typical compression ratios of 2:1 to 5:1 on text, source code, and structured data. Already-compressed data like JPEG images, MP4 video, or MP3 audio compresses poorly or not at all — this is why zipping a folder of photos barely reduces its size. ZIP stores each file independently, so tools can choose to store incompressible files uncompressed (method 0) while compressing text files with DEFLATE.

ZIP64: Breaking the 4 GB Barrier

The original ZIP specification stores file sizes and archive offsets in 32-bit fields, limiting individual files and total archive size to approximately 4 GB (2^32 bytes). ZIP64 extensions, introduced in APPNOTE version 4.5 in 2001, use extra fields with header ID 0x0001 to store 64-bit sizes. When any size field would overflow 32 bits, the local header writes 0xFFFFFFFF as a sentinel value and stores the actual 64-bit size in the ZIP64 extended information extra field.

All modern tools — 7-Zip, WinRAR, Windows Explorer (since Windows 8), macOS Archive Utility, Python's zipfile module (since Python 3.4) — handle ZIP64 transparently. Legacy tools from before 2001 silently truncate or refuse ZIP64 archives.

Security: ZIP Bombs, Zip Slip, and Weak Encryption

ZIP's ubiquity makes it a frequent attack vector. Three vulnerabilities stand out:

ZIP bomb (42.zip): A 42 KB file that decompresses to 4.5 petabytes through nested layers of 16 ZIP files each. Non-recursive variants use overlapping file references within the central directory to bypass depth-checking defenses, achieving massive expansion ratios in a single flat archive. Any extraction tool without decompressed-size limits is vulnerable.

Zip Slip (CVE-2018-1002200): A path traversal attack where archived filenames contain ../ sequences. During extraction, vulnerable libraries write files outside the intended directory — potentially overwriting executables, configuration files, or SSH keys. Discovered by Snyk in 2018, this vulnerability affected Java, .NET, Ruby, Go, and Python extraction libraries.

ZipCrypto weakness: The traditional PKWARE encryption scheme (ZipCrypto) is cryptographically broken. It uses a stream cipher seeded from a 96-bit internal state derived from the password, and is vulnerable to known-plaintext attacks. Tools like pkcrack can recover the encryption key in seconds if any file in the archive has known content. AES-256 encryption (added in APPNOTE version 5.2, implemented by WinZip and 7-Zip) is secure but not universally supported by all extraction tools.

Compression Comparison

ZIP compresses each file independently, which enables random access but limits compression ratio. Solid-archive formats like 7z and RAR compress all files as a single stream, exploiting cross-file redundancy for 30-70% better ratios on collections of similar files (such as source code repositories). The tradeoff: extracting a single file from a solid archive requires decompressing everything before it. ZIP wins on compatibility and random access; 7z wins on compression ratio; TAR.GZ wins on Unix metadata preservation.