Why Is Your ZIP File Bigger Than the Original? (Data Entropy Explained)

Why Your ZIP File Is Bigger Than the Original (And Why That's Not a Bug)

You right-click a file, hit "Compress," and watch the progress bar crawl. Then you check the result and your stomach drops a little: the ZIP is larger than what you started with. Not by much, but enough to notice. Did the compression tool break? Is your OS lying to you?

No. This is completely normal, and once you understand why, you'll stop wasting time zipping files that were never going to shrink in the first place.

The Short Answer

Compression algorithms like DEFLATE (used in ZIP), LZMA (used in 7z), and the various codecs inside RAR all work the same basic way: they hunt for repeated patterns and replace them with shorter references. If a file already has no repeated patterns to find — because it's already compressed, or because it's inherently random — the algorithm can't shrink anything. But it still has to wrap your data in a container: headers, a file table, checksums, maybe a dictionary structure. That container costs bytes. When there's nothing to save on one side and a fixed cost on the other, you come out behind.

This is the core of lossless compression overhead, and it's the answer to a question a lot of people search for the moment it happens to them: why does zipping increase file size instead of decreasing it.

Let's Actually Test This (No Trust Required)

I ran this on my own machine so you don't have to take my word for it — and you can reproduce every number below in about thirty seconds.

Test 1 — a genuinely compressible file: I generated a 1,000,000-byte text file containing nothing but the letter "A" repeated a million times. This is about as friendly to compression as data gets.

Test 2 — a genuinely incompressible file: I generated 10,000,000 bytes of raw random data using secrets token generation in Python. This stands in for something like an already-compressed JPEG, MP4, or MP3 — files where the "compression work" has already happened at the format level, so there's no redundant pattern left to exploit.

Look at the gap between those results. The repetitive file crushed down to a fraction of a percent of its original size — DEFLATE found the same byte over and over and replaced a million characters with a tiny instruction set. The random file, on the other hand, came out slightly larger than it started.

That growth isn't a glitch. It's the cost of doing business when there's no pattern to exploit:

• ZIP container overhead: Every archive carries a local file header, a central directory record, and an end-of-central-directory record for each file it holds. That's on the order of 100+ bytes of pure bookkeeping before a single byte of your actual data is touched.
• DEFLATE block overhead: DEFLATE splits data into blocks and, for each one, decides whether Huffman-coding it will help. When your data is high-entropy (statistically close to random), Huffman coding can't build a useful shorter-code table, so DEFLATE falls back to storing the block mostly as-is — but it still has to tag each block with metadata describing how it was stored.

Try zipping an actual .jpg or .mp4 on your own machine and you'll see the same shape of result: a small, almost comically modest size increase, usually somewhere between a few dozen and a couple thousand bytes depending on file size and archiver.

Data Entropy, Explained Without the Math Lecture

Here's the plain-English version of Shannon entropy, which is the formal concept underlying all of this.

Imagine you're asked to summarize two books.

Book One is 300 pages of a single sentence repeated over and over: "Hello world. Hello world. Hello world." You could summarize the entire book in five words: "It just says 'Hello world' repeatedly." Massive compression, almost no information lost, because almost no information was there to begin with.

Book Two is 300 pages where every single sentence is different, covers a different topic, and has no relationship to the sentence before or after it. There's no shortcut. To accurately convey the content, your "summary" basically has to be the book. You can't compress it because there's no redundancy to strip out — every sentence carries new, unpredictable information.

That unpredictability is entropy. Low-entropy data (repeated patterns, predictable structure — think plain text, uncompressed bitmap images, database logs with repetitive fields) has a lot of redundancy an algorithm can strip out. High-entropy data (already-compressed video, encrypted files, random noise) is closer to Book Two: dense, unpredictable, and already carrying close to the maximum amount of information per byte. There's nothing left to summarize.

This is exactly why an uncompressed .bmp will shrink dramatically in a ZIP, while a .jpg — which already ran its own compression pass at encoding time — will not, and might grow slightly instead.

Why Compression Algorithms Add Overhead In the First Place

It's worth understanding why the overhead exists instead of just accepting it, because it explains the tradeoff every archiver is making.

• Huffman coding: (used inside DEFLATE) works by assigning shorter binary codes to frequently-occurring bytes and longer codes to rare ones. To do that, it needs a code table describing which byte maps to which code. On highly repetitive data, that table is tiny compared to the space it saves. On random data, almost every byte occurs with roughly equal frequency, so there's no meaningful table to build — but a fallback structure still gets written.
• LZ77 and its descendants: (the "dictionary" half of DEFLATE, and the backbone of LZMA in 7z) scan backward through recently-seen data looking for matching sequences to reference instead of repeating. Incompressible data has no matches to find, so the algorithm spends effort searching, finds nothing, and still has to encode "no match here, here's the literal byte" markers.
• Archive-level metadata: File names, timestamps, CRC32 checksums for integrity verification, directory structures for multi-file archives — is a fixed cost that exists regardless of how compressible your data is. A single-file archive of a 10-byte file will always be dozens of bytes larger than the file itself, because the container has a non-negotiable minimum size.

RAR and 7z (LZMA) are more sophisticated than classic ZIP/DEFLATE and squeeze out slightly better ratios on compressible data, but they follow the identical rule on incompressible data: no redundancy in, no savings out, plus their own container tax.

The 3-Second Decision Guide

You don't need to run a benchmark every time you're about to zip something. Use this instead:

• Compress when the data is text-like or structurally repetitive: Logs, source code, CSVs, uncompressed images (BMP, TIFF), database dumps, JSON/XML exports. These have real redundancy, and you'll typically see 50–95% size reduction.
• Skip compression when the data is already compressed: JPG, PNG, MP4, MP3, most modern video/audio codecs, already-zipped files, and anything encrypted. You'll gain nothing and may lose a few bytes; you're better off leaving it raw or just using an uncompressed archive (a .tar with no compression, or a ZIP with the "store" method) purely for bundling multiple files together, not for shrinking them.
• When in doubt, test on a sample first: Zip a small representative chunk of your actual dataset before committing to compressing a multi-gigabyte archive. If the ratio isn't at least noticeably below 100%, don't bother — you're paying CPU time and archive overhead for nothing.

The next time a ZIP comes out slightly larger than the original, you'll know exactly what happened: the algorithm looked for redundancy, correctly found none, and honestly reported the small fixed cost of wrapping your data in a container. That's not compression failing — that's compression working exactly as designed.