How ZIP Compression Works, and Why Some Files Barely Shrink

ZIP shrinks files by finding repetition. Its standard method, DEFLATE, replaces repeated stretches of data with short back-references, then stores the most common bytes in fewer bits. Files with a lot of repetition, such as logs and text, shrink dramatically. Files that are already compressed, such as JPEGs, MP4s and most PDFs, have no visible repetition left, so ZIP can do almost nothing for them.

We zipped a set of real files with our Create ZIP tool’s function, which uses DEFLATE, one file at a time:

Those results follow directly from how the algorithm works.

DEFLATE in two steps

DEFLATE is defined in RFC 1951. It combines two old and simple ideas.

Step one: replace repeats with references (LZ77)

The compressor reads through the data, and each time it finds something that has appeared recently, it writes a short note instead of the bytes: “go back this far, and copy this many”.

Take this sentence:

the cat sat on the mat

The second the can become “go back 15 characters, copy 4”. And at in mat can point back too. On real files, the matches are much longer. All those log lines beginning with a similar timestamp and the same path are nearly one long string of references.

There is a limit to how far back it can look. The RFC sets a maximum distance of 32 KB, called the sliding window. Anything older is out of reach. We can show this with Python’s zlib, which implements DEFLATE, using 1,000 random bytes that appear twice:

In the first two rows, the second copy compressed away almost entirely. In the third, the first copy had left the window, so the repeat was invisible and nothing was saved. This small window is one of DEFLATE’s main limits. Newer methods such as Zstandard and LZMA, used by 7-Zip, can look much further back.

Step two: shorten common symbols (Huffman coding)

A normal byte takes 8 bits, whether it is a common letter or a rare symbol. Huffman coding gives frequent symbols shorter codes and rare ones longer codes, much as Morse code gives E a single dot.

In English text, spaces and e come up all the time, so they might take 3 or 4 bits, while a rarely used symbol might take 12. Both the literal bytes and the back-references from step one go through this stage. Each compressed block includes the code table it needs, or uses a fixed default.

That gets you the saving on the RFC itself: 69.5%, a factor of about 3.3, a little better than the RFC’s own note that English text usually compresses by a factor of 2.5 to 3.

Why some files barely shrink

A compressed file looks random, and random data has no repeats to reference and no common bytes to favour. There is a counting argument in the RFC that explains why no lossless compressor can shrink every input. Some must grow. For DEFLATE, the worst case is 5 bytes per 32 KB block, and in our table you can see that in the random file, and in the files that “grew”. ZIP’s headers add a little as well, which is why tiny files can also get larger.

That applies to:

• JPEG, WebP and AVIF images. Their encoders have already squeezed out what they can.
• PNG. It uses DEFLATE internally, so a second DEFLATE finds little. The screenshot still saved 11% because that PNG was not strongly optimised.
• MP3, AAC, MP4 and most video. Same reason.
• PDF, DOCX, XLSX and PPTX. These are compressed containers already. A DOCX is itself a ZIP, as we show in what is inside a DOCX file.
• Encrypted files. Good encryption output is indistinguishable from random. This is why you should always compress first, and encrypt second.

So to make a folder of photos smaller, zipping is the wrong tool. Reduce the images themselves, as covered in how to reduce image file size. Zipping is still useful as a way to package many files into one download. Compare the BMP and PNG rows, too: format-aware compression tends to beat a general tool on its own ground.

The screenshot at 98.1% and the photo at 32.9% were both uncompressed BMP files. The difference is all content. Flat areas and repeated rows are full of repetition, and camera noise has none. Compression ratio tells you about what is in a file, not how good the tool is.

How a ZIP file is organised

A ZIP compresses each file separately, then adds a central directory at the end listing every name, size and position. Two useful things follow from this:

• Listing is instant. A reader can jump to the end and read the list without decompressing anything. Our ZIP File List tool does this, so you can see what is in a ZIP before extracting it.
• Identical files do not help each other. Since each is compressed on its own, ten copies of a file take ten times the space. A “solid” format such as .tar.gz or a solid .7z compresses everything as one stream, so it can do better on many similar files, at the cost of slower access to a single file.

Our Create ZIP tool applied DEFLATE to every file in this test, which is why a few entries in our table grew by a small amount. It also has a “Store only” setting that skips compression, which is the faster and very slightly smaller choice for a folder of photos or videos.

ZIP passwords: know which kind you have

ZIP’s original password scheme is known as ZipCrypto. PKWARE, who created the format, say in the ZIP specification that it “is considered weak by today’s standards” and should be used only for low security needs or for compatibility. A known-plaintext attack has been public since the 1990s: an attacker who knows or can guess part of one file in the archive can recover the keys, with no need to guess the password. That is a realistic risk, because archives often hold files with predictable content, such as a standard document header.

It is still widely used, since it is the method with the widest compatibility. On a Mac or Linux, zip -e or zip -P uses it. Stronger AES-256 encryption is available through tools such as 7-Zip and WinZip, and you should choose it specifically, because it is not always the default.

Encryption in ZIP has a limit that surprises people, whichever cipher is used: it protects file contents, not the list of files. We made an encrypted archive with zip -P, then listed it without a password:

$ unzip -l enc.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
    36944  11-03-2026 04:16   rfc1951.txt
  4029932  11-03-2026 04:16   server.log
---------                     -------
  4066876                     2 files

Reading the contents required the password, as expected, but the file names, sizes and dates were all plain to see. Python’s zipfile also read each file’s CRC-32 checksum without a password. If a file name such as layoffs-2026-final.xlsx is itself sensitive, you have a problem. The .7z format can encrypt the file list too, with 7-Zip’s “Encrypt file names” option.

In short:

• For keeping out casual snoops, any ZIP password does the job.
• For anything sensitive, use AES-256 with a long random password, and send the password by another channel. 7-Zip or a similar archiver will give you this.
• If the file names are sensitive, use .7z with encrypted names, or put the archive inside another encrypted container.

Our Create ZIP tool does not encrypt at all, so do not use it for confidential material unless you encrypt separately. It runs in your browser, and packs your files without sending them anywhere. For encrypting a PDF specifically, the same weak-versus-strong issue exists, as we discuss in is PDF password protection secure.

When to reach for something other than ZIP

That last row is why ZIP is still everywhere, after more than 35 years. Other formats compress better, and hardly anybody has to install anything to open a ZIP.