What is a zip bomb?

How a zip bomb works: ratio and nesting

Start with compression ratio. DEFLATE, the algorithm used inside zip and gzip, is very good at repetitive input and very bad at random input. A file that is one byte repeated millions of times compresses to a few kilobytes; a JPEG or an already-compressed file barely shrinks at all. A bomb author crafts input that is maximally compressible, so the unpacked form is huge while the archive stays small. Single-layer ratio bombs can reach roughly a 1-to-1000 expansion on the right data.

Nesting multiplies that. A zip can contain another zip, which contains another, and so on. If every layer expands by a thousand times, then sixteen layers expand by a thousand to the sixteenth power — a number so large it stops being meaningful in bytes. This is exactly how 42.zip reaches its roughly 4.5 petabyte figure: not from one impossible compression ratio, but from sixteen layers of ordinary high-ratio compression stacked on each other.

A more clever variant, described publicly by security researcher David Fifield in 2019, uses *overlapping* zip entries — a quirk of the format where multiple entries point at the same compressed bytes — to push the ratio of a single file far beyond what naive nesting achieves. The takeaway is the same: the file you download is tiny, and the bytes it claims to contain are enormous.

• High ratio: a block of repeated bytes can compress ~1000×, so one layer already explodes in size.
• Nesting: zips inside zips multiply each layer’s ratio — 42.zip stacks 16 layers for ~4.5 PB.
• Overlapping entries: a format quirk lets advanced bombs reuse the same compressed bytes for huge ratios in one file.
• The archive stays tiny; only faithful (and ideally recursive) extraction reveals the explosion.

Why modern systems shrug off most bombs

Twenty years ago a zip bomb was a genuine threat to a desktop machine: a naive extractor with no size limit would happily write until the disk was full and the OS froze. That is much less true today. Browsers impose per-tab memory limits, disk space is cheap and watched, and competent decompression libraries carry explicit "is this a bomb?" checks that refuse ratios beyond a threshold or sizes beyond a cap.

The realistic outcome now is that a bomb makes a single application or browser tab run out of memory and reload — annoying, not catastrophic. It will not overwrite your operating system from a browser tab, and it will not silently fill a modern terabyte drive the way it once filled a 40 GB one. It is still a real denial-of-service concept, still a reason to avoid extractors that impose no limits at all, and still dangerous to automated pipelines (antivirus scanners, email gateways, CI jobs) that decompress untrusted input without bounds.

Browsing vs extracting: the difference that matters

A zip file keeps a small index at the end called the central directory — the table of contents that lists every entry by name and size. Reading that index is all that is required to show you the file tree. The actual compressed payload of each entry is never touched until you ask to open that specific file. This is why *browsing* a zip and *extracting* a zip are very different operations from a safety standpoint.

When you open an archive in ZipTool, building the file tree reads only the central directory. No entry payloads are decompressed until you click into one. That means inspecting a suspicious zip — seeing its structure, its names, its declared sizes — triggers no mass decompression and therefore no explosion. Nested archives do not auto-cascade either: an inner .zip appears as an ordinary entry you would have to deliberately open layer by layer, so a nested bomb like 42.zip cannot recurse through the layers on its own the way it can against a tool that auto-extracts every archive it sees.

One honest caveat. ZipTool’s "extract all" writes every entry to a folder you choose (through your browser’s File System Access API), so the ordinary caution about disk space applies there — extracting a genuine high-ratio bomb to disk is still extracting a bomb. Previewing the tree is the low-risk path; large-scale extraction of an untrusted archive is where you re-introduce the original risk. See security and privacy for the full threat model.

• Browsing reads only the central directory — no payload bytes are decompressed.
• Nested archives appear as entries; they do not auto-extract recursively, so 42.zip can’t cascade on its own.
• Previewing a single oversized entry can exhaust one tab’s memory (sandboxed) but cannot fill a disk or crash the OS.
• Extract-all writes to disk, so normal disk-space caution still applies to large-scale extraction of untrusted archives.

How to inspect a zip you do not trust

A few habits cover almost every real case, and none of them require anything fancy. The guiding idea is always the same: look before you extract, and never let a tool auto-extract recursively into something important.

Preview the tree first. Drop the archive into ZipTool and read the file list before extracting anything to disk. Browsing triggers no decompression and no execution, so it is low-risk. Look for the classic warning signs described below.

Do not auto-extract recursively. A bomb and many delivery attacks rely on a tool that walks into nested archives on its own. ZipTool does not; each inner archive is a deliberate click. Keep that habit in any extractor you use.

Keep your browser updated. The sandbox and the decompression code both improve with patches; an up-to-date browser is one of the strongest practical defenses against any in-browser parser issue.

• Preview the file tree in a no-upload viewer before extracting to disk.
• Do not let any extractor auto-recurse into nested archives.
• Keep your browser updated so the sandbox and parser stay patched.
• For a confirmed bomb, the safe action is to not extract it at all — delete it.

Spotting a bomb at a glance

You can usually tell a bomb is suspicious from the central directory alone — the very thing ZipTool shows you before decompressing anything. The signatures are extreme: a tiny archive whose entries declare huge uncompressed sizes, a handful of files each claiming gigabytes, or nested .zip entries stacked several layers deep.

None of these is proof on its own — a legitimate backup or a game asset pack can also be large. But a 40 KB file whose contents list as hundreds of gigabytes is not a game asset; it is a bomb or a corrupt archive, and in either case the right move is to close it and not extract. The ratio between the archive size on disk and the sum of the declared uncompressed sizes is the single most telling number, and you can read it directly from the file tree without decompressing a single payload byte.

• Tiny archive on disk but entries declare huge uncompressed sizes.
• A few files each claiming gigabytes inside a kilobyte-scale archive.
• Nested .zip entries stacked several layers deep.
• A disk-size-to-declared-size ratio in the thousands or more — the classic bomb signature.

Are zip bombs malware?

Not in the self-replicating, data-stealing sense most people mean by "malware." A zip bomb is a denial-of-service payload: it does not run code, steal data, or spread itself; it simply tries to exhaust a resource (disk, memory, CPU) when something tries to unpack it. Its effect depends entirely on the tool that opens it.

That said, bombs are often used *by* malware and *against* security tools. An attacker attaches a bomb to an email or hides it inside a payload precisely so that an antivirus scanner or mail gateway — which dutifully decompresses everything to inspect it — exhausts its memory and either crashes or gives up, letting the real malicious file slip past. The bomb is a shield for something nastier, not the nasty thing itself. For more on how archives are used as a delivery wrapper, see security and privacy.

Frequently asked questions