I’ve probably opened thousands of ZIP files without thinking much about the format itself. Double-click, extract, move on. Then I learned that if you peel away the friendly folder icon and look at an ordinary ZIP archive in a hex editor, there’s a tiny calling card buried in the machinery: 50 4B. In ASCII, those bytes read PK, the same initials as Phil Katz, the programmer behind PKZIP and one of the people who created the ZIP format.
They’ve been riding around inside our archives since 1989, and they’re still showing up in files that don’t even end in .zip.
ZIP keeps saying “PK” in hex
Your archive has been name-dropping Katz
Open a typical ZIP archive in a hex editor, and there’s a good chance the first four bytes will be 50 4B 03 04. The 50 maps to P in ASCII and 4B maps to K. Together, 50 4B 03 04 forms the signature for a local file header, the record that sits in front of an archived file and describes what follows. It’s also a neat example of how identifying files by their hex signatures can reveal the format underneath a filename.
ZIP uses a whole family of these signatures. A central-directory entry begins 50 4B 01 02, while the end-of-central-directory record begins 50 4B 05 06. PKWARE’s APPNOTE notes that these record signatures share a two-byte constant representing the characters PK. The remaining bytes distinguish the different records that make up an archive, including file headers, central-directory entries, and the archive’s ending record.
There’s a fun technical catch here. A ZIP file does not have to begin with PK. Self-extracting archives can put executable data before the ZIP structures, and other leading data is possible. What ZIP actually requires is an end-of-central-directory record. Even an empty ZIP consists of that record, so 50 4B still turns up somewhere inside it.
You can verify this yourself in seconds. Make a small ZIP and open it in a hex editor, and on a typical archive, 50 4B 03 04 will probably be sitting right at the beginning. Once you know what those first two bytes spell, it’s quite hard to unsee.
A lawsuit helped push Katz toward a new format
Nothing motivates quite like getting sued
Katz didn’t arrive at ZIP by deciding one day that computers needed another archive format. Before PKZIP, he wrote PKARC, an ARC-compatible archiver that became popular in the bulletin-board-system world, partly because of its speed. ARC was already a common way of bundling files for distribution over BBSes, so compatibility gave PKARC an existing ecosystem to walk into. ARC belonged to System Enhancement Associates, or SEA, and the similarities eventually landed Katz and PKWARE in court.
SEA sued PKWARE and Katz over the ARC-compatible software, and the dispute ended in a settlement in August 1988. Under the agreement, PKWARE could continue distributing its ARC-compatible programs under license only through January 31, 1989. After that, the company agreed not to publish or distribute ARC-compatible programs.
The break pushed Katz toward his own format. He developed ZIP with Gary Conway of Infinity Design Concepts, and the format appeared publicly in 1989 alongside PKZIP. Early documentation distributed with the software explicitly dedicated both the ZIP file format and the .ZIP extension to the public domain.
That openness gave other developers enough information to build compatible software without depending on PKZIP itself, helping ZIP spread well beyond PKWARE’s own tools. Speed and the shareware ecosystem helped too. BBS operators and PC users already knew Katz’s software, and ZIP arrived at a moment when moving smaller files faster over dial-up connections was a fairly compelling sales pitch.
One detail that often gets compressed out of this story is DEFLATE. ZIP is a container that can use different compression methods, which is why the difference between archiving and compression is useful here. The Library of Congress chronology places DEFLATE’s introduction in APPNOTE 2.0 in 1993. Katz designed DEFLATE as well, but it wasn’t part of the original 1989 ZIP specification.
His initials escaped the .zip extension
Word documents have been carrying the evidence
The part I find funniest is that you don’t need to create a .zip file to keep running into Katz’s initials. ZIP became plumbing for other formats.
Microsoft’s Office Open XML formats use ZIP-based packaging, which is why you can open a .docx, .xlsx, or .pptx file as an archive and find a collection of XML files and folders inside. EPUB 3.3 requires its publication container to use a constrained ZIP format. Oracle’s Java documentation describes JAR as being based on ZIP too.
That means the same PK signatures can sit inside a Word document, an ebook, or a Java archive while the person using it has no reason to think about ZIP at all. The file extension changed, the job changed, and the surrounding standards grew far beyond the DOS utility Katz released in 1989. The underlying structure kept enough continuity that those two bytes survived.
Two bytes with an absurdly long shelf life
Most software legacies are visible in screenshots, old hardware, or code somebody still has to maintain. Katz’s is stranger because it keeps getting copied into fresh files every day. I can save a new Word document in 2026, peel back the packaging, and find the same PK marker that dates to the ZIP design of 1989. For two hexadecimal bytes, that’s a ridiculous career.
