What is a zip bomb?

A zip bomb is an archive that is small on disk and enormous once extracted. The classic example, 42.zip, is 42 kilobytes. Unpacked all the way down it is about 4.5 petabytes.

There is no exploit involved. Nothing about a zip bomb is malformed, and no vulnerability is being triggered. It is just compression, used honestly and pointed somewhere unkind.

How the trick works

DEFLATE, the algorithm behind almost every ZIP file, replaces repeated data with references to earlier data. Text compresses well because words recur. Photographs barely compress at all, because the noise in them never repeats.

Now take the most repetitive file possible: a few hundred megabytes of the same byte, over and over. There is nothing to store except “this byte, that many times.” A file of nothing but zeroes compresses roughly a thousand to one.

That is the whole mechanism. A one-megabyte entry becomes a gigabyte. Ten of them become ten gigabytes, out of an archive you could email.

The bombs that get written about go further by nesting. 42.zip contains sixteen archives, each of which contains sixteen more, five layers deep, and only at the bottom sit the actual files of repeated bytes. Each layer multiplies, so the total is 16⁵ files rather than the few dozen you can see from the top.

What it is actually used for

Rarely against people. Extracting a zip bomb by hand fills a disk, which is annoying and then over.

The real target is software that unpacks archives without being asked — antivirus scanners, mail gateways, upload handlers, indexing services. Anything that receives a file and decompresses it to look inside can be made to write petabytes, or to exhaust memory and fall over. A mail filter that dies on every message is a mail filter that has stopped filtering.

Any decent scanner has had ratio and depth limits for many years now, so this is much more a hazard for a service someone wrote in a hurry than for your laptop.

Seeing the expansion without extracting

Here is the part that makes zip bombs easy to catch: a ZIP file tells you how big its contents are before you decompress anything.

Every ZIP ends with a central directory — an index listing each entry, its compressed size and its uncompressed size. Reading it takes milliseconds regardless of how large the archive claims to be. So the compressed and uncompressed totals are available up front, and the ratio between them is arithmetic.

That is exactly what the file.zip inspector does. Open an archive and it reads the central directory in your browser, lists every entry with both sizes, and flags the ones whose numbers do not look ordinary.

Where file.zip draws the line

The thresholds are deliberately high, because ordinary files compress surprisingly well. Log files, CSV exports, JSON dumps and sparse disk images routinely hit 50x to 200x. Warning at those levels would mean warning about normal archives, and a warning that fires constantly is one people learn to click past.

A single entry is flagged when it expands 1,000x or more and reaches at least 100 MB, or 150x or more and reaches at least 2 GB. Ratio alone is not enough — a 3 KB file that expands 1,000x is 3 MB, which is nobody’s problem. Entries under 256 compressed bytes are left out of this per-entry check, since a ratio computed over a handful of bytes is noise. They still count towards the archive-wide totals below.

When no single entry stands out, the archive is measured as a whole instead, and flagged when it expands 200x or more and totals at least 1 GB. That catches a bomb spread thinly across many files rather than concentrated in one. These two are deliberately exclusive: if individual entries were already named, repeating the same expansion as an archive-wide warning tells you nothing new.

Failing both, an archive whose contents exceed 20 GB still gets a plain note — not because anything is wrong, but because you should know before you pick a destination folder.

The nesting caveat, stated plainly

A recursive bomb like 42.zip does not trip the ratio check, and it is worth understanding why rather than assuming the check has failed.

Compression ratios describe one layer. The entries inside 42.zip are themselves compressed archives, and compressed data barely compresses again — so from the outside, 42.zip looks like an archive containing sixteen files that barely shrank. Utterly unremarkable. All the expansion is hiding one level down.

So file.zip reports what it can actually see. When an archive contains nested archives it says so, notes that the ratios above describe only the outer layer, and marks it as worth attention when nested archives are most of the contents — five or more, or over half the entries. It does not recurse automatically. Extract a nested archive and open it in the inspector to measure the next layer yourself.

That is the honest boundary. The tool measures the layer in front of you and tells you when there are layers it has not measured.

One more caveat: the sizes are self-reported

The uncompressed sizes come from the archive’s own central directory. A deliberately malicious archive can lie there — declare an entry as 1 KB and actually deliver gigabytes when decompressed. Any tool that reads metadata rather than decompressing has this limitation, and it is worth knowing about.

In practice it does not much change the advice. A lie that helps an attacker has to understate — overstating the size only trips the warning sooner. So the archives that declare a 4,000x expansion are telling you the truth about something you would rather know. And the reason inspecting in a browser is safe is not that the numbers are trustworthy — it is that reading the index never decompresses anything, so a bomb that lies about its size still has not been given the chance to expand.

What to do if an archive is flagged

Not necessarily panic. The finding is a description of what was observed, not a verdict.

Ask whether the numbers match what you were expecting. A 40 GB expansion in a database backup is what a database backup looks like. The same expansion in something described as “photos from the weekend” is not.

Look at what the entries are. A bomb is repetitive filler with unrevealing names. A legitimately compressible archive contains recognisable files with recognisable names.

And if you have no explanation for it, the safe move is simply not to extract it. Nothing has been decompressed to get you this far, so closing the tab costs you nothing.