What Is a ZIP File? (PKWARE's 1989 Format Behind the World's Most Common Archive)

Phil Katz's DEFLATE algorithm, the central directory that makes per-file access possible, ZIP64 for large archives, and the real gap between weak and strong ZIP encryption.

  1. Add a file Choose or drop it here
  2. Pick the format Change it whenever needed
  3. Download the result After conversion completes

The 1989 Format Born Out of a Lawsuit

A .ZIP file is a multi-file archive format PKWARE publicly released in February 1989, built by Phil Katz through his PKZIP utility. The format's origin traces directly back to a specific legal dispute: Katz had earlier rewritten and released as freeware a compression tool derived from source code belonging to System Enhancement Associates (SEA), and after SEA won a lawsuit against him over it, Katz built ZIP as an entirely new format using different compression techniques, then made a deliberate choice that shaped its future — he published the APPNOTE.TXT specification openly and declared ZIP would always be free for any competing software to implement.

That openness is arguably the single biggest reason ZIP became as universal as it is today: because no company controls or licenses the core format, operating systems, programming languages, and countless software libraries could all build native ZIP support without any legal friction, something that never happened at the same scale for more restricted formats.

This history also explains why ZIP's file extension shows up disguised inside so many other, seemingly unrelated file formats today. Modern .docx, .xlsx, .pptx, .jar, and .epub files are all, structurally, ZIP archives underneath a different extension, holding an internal folder of XML or class files that a compliant ZIP reader can open directly if the extension is simply renamed to .zip. This wasn't an accident — Microsoft, Java's creators, and the ePub standard's authors all deliberately chose to build their newer formats on top of ZIP's already-proven, freely implementable archive structure rather than invent a new container format from scratch.


DEFLATE Compression and the Central Directory That Indexes Every File

ZIP's default compression method is DEFLATE, an algorithm Phil Katz designed specifically for PKZIP version 2, combining LZ77-style back-referencing within a 32 KB sliding window with Huffman coding as a final entropy-coding stage. DEFLATE was later formally specified in RFC 1951 in 1996, well after it had already become ZIP's practical default. Each file inside a ZIP archive is compressed independently with its own local file header, rather than all files sharing one continuous compressed stream, which is what lets a ZIP tool add, replace, or extract a single file without touching anything else in the archive.

Making that per-file access fast relies on the central directory, a structure positioned at the very end of the ZIP file that lists every entry's name, compressed and uncompressed size, and the exact byte offset where that entry's data begins. A program reading a ZIP archive can jump straight to the central directory, read the full file list in one pass, and then seek directly to any specific entry rather than scanning through the entire archive from the beginning — a structural design choice that has aged remarkably well since 1989.

Every entry in a ZIP archive also carries a CRC-32 checksum, calculated from the uncompressed file's contents, stored both in the local file header and again in the central directory. This lets an extraction tool verify a file wasn't corrupted somewhere along the way, whether from a bad download, a damaged storage medium, or any other transmission error, by recomputing the checksum after decompression and comparing it against the value stored in the archive — a basic but genuinely useful integrity check built into the format from the very beginning.


What ZIP's Design Gets Right and Where It Genuinely Falls Short

  • Gain — near-universal native support: Windows File Explorer has read and written ZIP since Windows XP's "Compressed Folders" feature, and macOS Finder offers equivalent built-in handling.
  • Gain — genuine per-file access via the central directory: individual files can be extracted, replaced, or previewed without processing the whole archive.
  • Lose — a compression ratio behind newer, more advanced algorithms: DEFLATE's fixed 32 KB window generally compresses less tightly than LZMA2 or even bzip2 on the same data.
  • Gain — optional real encryption, if configured correctly: AES-256 encryption, added by WinZip in 2003 as an extension to the format, is genuinely strong when actually used.
  • Lose — a false sense of security from the format's older default encryption: ZipCrypto, the original built-in encryption scheme, can be cracked in seconds with freely available tools regardless of password strength.
  • Lose — reliable Unix permission preservation: the original specification wasn't designed around Unix ownership and permission metadata the way TAR always was.

Where ZIP64 Quietly Took Over Once Files Got Bigger

The original ZIP specification capped an archive at 65,535 files and roughly 4 GB per file or per archive, limits that were entirely reasonable in 1989 but became a real constraint as storage and file sizes grew over the following decade. PKWARE addressed this with the ZIP64 extension, which WinZip first supported starting with WinZip 9.0 in 2004, removing those original ceilings and letting a ZIP archive scale to sizes limited only by the underlying filesystem rather than the format's own original header fields.

Most current ZIP-handling software automatically starts an archive as a standard ZIP and transparently upgrades it to ZIP64 the moment file count or size crosses the old thresholds, which means the vast majority of users never notice the switch happening. The exception is genuinely old ZIP software that predates 2004's ZIP64 support, which can fail to open or misreport a large modern ZIP64 archive as corrupted, since it was never built to parse those extended header fields at all.

Windows itself also enforced the original 65,535-file and roughly 4 GB limits for longer than the ZIP64 extension had technically existed, since File Explorer's built-in "Compressed Folders" feature took time to catch up to what WinZip and other third-party tools already supported starting in 2004. This gap between a format extension existing and every mainstream tool actually implementing it is a recurring pattern across ZIP's history, not unique to ZIP64 specifically, but it's the most concrete, size-related example most users are likely to run into directly.


The Real Difference Between "Password Protected" and Actually Secure

A specific, well-documented and frequently misunderstood problem with ZIP encryption is that not all "password protected" ZIP files offer the same level of real protection. ZipCrypto, the encryption method built into the original ZIP specification and still what many older or default archive tools apply, has known cryptographic weaknesses serious enough that a determined attacker can crack it in seconds using freely available tools, regardless of how strong the chosen password is. AES-256 encryption, which WinZip added as a ZIP extension in 2003 using an SHA-256-based key derivation function, is the version that actually deserves to be called secure, but it requires the creating tool to specifically choose AES over the older default.

This distinction causes real, documented confusion in support forums, where someone assumes their password-protected ZIP file is safe from any determined attacker simply because it prompts for a password, without realizing that the specific encryption method chosen, not the mere presence of a password prompt, is what actually determines whether that protection means anything. Checking whether a given archive tool defaults to AES-256 rather than ZipCrypto, and manually selecting AES if the option exists, is the documented way to avoid this specific and easily overlooked gap.


ZIP's Original 1989 Limits Set Beside Its Modern ZIP64 Extension

Feature Original ZIP (1989) ZIP64 Extension
Maximum files per archive 65,535 Limited only by system resources
Maximum file/archive size ~4 GB Effectively unlimited
Introduced February 1989 WinZip 9.0, 2004
Default compression method DEFLATE DEFLATE (unchanged)
Backward compatibility N/A Fails on pre-2004 ZIP software

Common Questions About How ZIP Actually Works

Who actually created the ZIP format?
Phil Katz, through his company PKWARE, released the ZIP specification publicly in February 1989, building it after a lawsuit forced him to move away from an earlier compression tool based on someone else's code.

Is a password-protected ZIP file always secure?
Not necessarily. If it uses the older ZipCrypto method, it can be cracked in seconds regardless of password strength. Only ZIP files using AES-256 encryption, an extension WinZip added in 2003, offer genuinely strong protection.

Why does my old software fail to open a large ZIP file?
Very large archives require the ZIP64 extension, introduced in WinZip 9.0 in 2004. Software older than that, or built without ZIP64 support, can fail to open or misread these archives.

Can a ZIP file hold more than one type of compressed data?
Yes. Each file inside a ZIP archive is compressed independently, and while DEFLATE is the near-universal default, the specification also permits other per-file compression methods in tools that support them.

Why do some other file types actually contain a ZIP archive inside?
Formats like .docx, .xlsx, .pptx, and .epub are all built on top of ZIP's container structure, holding internal XML files. Renaming one of these to .zip and opening it with any ZIP tool reveals that internal folder structure directly.