A ZIP is a container before it is a compressor

Two independent jobs hidden behind one button

“Compress these files” often asks for two things at once:

1. Put several named files into one object that is easy to move, attach or download.
2. Use fewer bytes than the files used separately.

ZIP can do both, but the first does not depend on the second. The format calls an uncompressed entry method 0. It calls the familiar DEFLATE entry method 8. A method 0 archive is not a fake ZIP or a wrapper around some other format; it has the same entry records and central directory as a compressed ZIP, with source bytes placed directly in the data area.

This distinction matters because many modern files have already done the second job themselves. A JPEG describes image information with a specialised lossy codec. An MP4 contains compressed audio and video streams. A ZIP contains compressed entries. Running a general-purpose compressor over those bytes is like trying to vacuum-pack something that is already rigid: the container can still be useful, but there may be no air left to remove.

What storage still buys

Suppose a client needs three photographs, a signed PDF and a short MP4. Five loose attachments can be misplaced or downloaded separately. One ZIP fixes a single outer name and keeps five entry boundaries and names together. Each entry has its own size and CRC-32, and the central directory lets a reader list or extract one entry without guessing where it starts.

Storage therefore has real value even if the byte count rises slightly:

• one artifact instead of several;
• stable entry names and boundaries;
• a directory that archive software can inspect;
• an error-detection value for each extracted entry;
• exact source bytes, with no media conversion.

The cost is structural overhead. For every entry, ZIP records a local header near its data and another record in the central directory. Filenames appear in both places. Streaming writers can also add a data descriptor after the entry, because the CRC-32 and compressed size are not known when the local header is first emitted. A final record closes the directory. Small files can therefore show a large percentage overhead even though the absolute increase is only a few hundred bytes.

Before you read on

Ten JPEG photos total 24 MB. Store mode creates a 24.002 MB ZIP, while DEFLATE creates a 24.006 MB ZIP more slowly. Which result is behaving correctly?

• AOnly DEFLATE; compression must be used in a ZIP.

  Method 0 storage is a standard ZIP method, and the larger DEFLATE result found no useful redundancy.

• BOnly Store; a compressed ZIP may never exceed its input.

  DEFLATE can add a little representation overhead when its input is already compressed.

• CBoth; Store is the better choice for this set.

  Yes. Both are valid ZIPs, and the measured stored result is smaller and faster here.

Both results are valid, and Store is the better choice for this selection. Method 0 copies each JPEG byte and adds ZIP structure, explaining the small 2 KB increase. Method 8 then tries to describe already-compressed JPEG bytes with DEFLATE; if it finds no useful repetition, its block representation can add a few more bytes, explaining the 6 KB increase and extra work. The purpose of this ZIP is one container, not a second image compression pass.

Where DEFLATE earns its place

DEFLATE combines repeated-string references with compact codes for the symbols that remain. It performs well when the source repeats words, keys, delimiters, indentation, records or long byte sequences. Text files, CSV exports, JSON, logs, source code, XML and some uncompressed binary formats often provide that shape.

Compression level changes how much effort the encoder spends looking for a better description. It does not change what a reader must support. A level 1 stream and a level 9 stream are both ZIP method 8, and the same DEFLATE decoder opens both. Higher effort is therefore a trade rather than a compatibility upgrade: it can save a little more, take much longer, or produce exactly the same size on a simple input.

Filenames are evidence, not proof. A .txt file is likely compressible and a .jpg is unlikely to be, but a text file containing base64-encoded compressed data may resist DEFLATE, while an unusual PDF with large uncompressed streams may shrink substantially. If transfer size matters, the archive’s measured byte count is the answer. If latency matters more, choose based on the dominant format and avoid spending time to establish a two-kilobyte difference.

Why compressing twice usually fails

A successful compressor removes predictable structure. Its output is intended to resemble a sequence where the next bits are difficult to predict without decoding what came before. Another general-purpose compressor sees fewer repeated strings and less biased symbol frequency than the original data had.

That is why these starting choices are usually sensible:

Dominant material	First choice	Reason
JPEG, PNG, WebP, AVIF	Store	The image codec already compressed pixel information
MP3, AAC, MP4, WebM	Store	Media streams already use specialised codecs
ZIP, gzip, 7z	Store	The payload is already an archive or compressed stream
Modern mixed PDF	Store, then measure if size matters	Images, fonts and page streams may already be compressed
TXT, CSV, JSON, XML, source code	Balanced DEFLATE	Repeated text and structure usually compress well
Raw dumps or uncompressed bitmaps	DEFLATE and measure	Repetition depends on the source data

No quality is at risk in either column. ZIP storage is byte-preserving, and DEFLATE is lossless. The failure mode of a second compression pass is wasted time or a slightly larger representation, not a degraded photograph.

CRC-32 answers a smaller question than SHA-256

ZIP stores a CRC-32 for each entry. When software extracts a file, it calculates the CRC-32 of the reconstructed bytes and compares it with the recorded value. That catches common accidental corruption: a damaged download, failing storage or an incomplete copy is unlikely to produce the same value by chance.

It does not authenticate the entry. CRC-32 is not designed to resist a person choosing changes, and a person who can replace the bytes can replace the recorded CRC-32 too. It also says nothing about who supplied the outer ZIP.

A SHA-256 checksum has a different role. If two parties obtain a trusted digest through a channel independent of the file, they can test whether their whole ZIPs are byte-for-byte identical. Even that does not identify the author unless the digest itself is authenticated. A digital signature ties bytes to a key; authenticated encryption can add confidentiality and integrity. Plain ZIP storage and DEFLATE do neither.

A practical choice sequence

1. Decide whether the main goal is one container, fewer bytes, or both.
2. Look at the dominant data. Choose Store for already-compressed media and archives; choose Balanced DEFLATE for text and structured data.
3. Create the ZIP and compare its reported byte count with the source total.
4. If a mixed archive is large enough for the difference to matter, try the other mode once and keep the measured winner.
5. Do not read a CRC-32 pass as proof of origin. Publish or compare a separately trusted checksum when identical delivery matters, and use a signature or encrypted archive application when the threat is deliberate.

The useful mental model is simple: ZIP is the box; storage or DEFLATE is how each item sits inside it. A good box can be worthwhile even when nothing inside gets smaller.