Zipping is so routine that most people have never wondered what the operation actually does. It matters more than it seems, because it explains three things that otherwise look like bugs: why some folders shrink to a tenth and others do not shrink at all, why an archive can arrive larger than its contents, and why a few megabytes can be genuinely dangerous.
An archive is a container and a compressor, and they are separable
A zip file does two jobs that people run together in their heads.
The first is archiving: taking many files with names, paths, timestamps and permissions, and putting them into a single file with an index. The second is compression: making the data smaller.
Those are independent. The format records a compression method per entry, and one of the valid methods is no compression at all. Method 0 is store, meaning the bytes are copied in verbatim. Method 8 is DEFLATE, the algorithm almost everything actually uses. An archive can mix them freely, choosing per file.
This is not a curiosity. Our own zip engine has two writers precisely because of it: a store-only writer used by tools that bundle output which is already compressed, such as a batch of JPEGs or extracted PDF pages, and a DEFLATE writer used when the contents are arbitrary and might genuinely benefit. Compressing a folder of JPEGs would burn real time to save a rounding error, so the correct engineering answer is not to try.
What DEFLATE actually does
DEFLATE combines two ideas, and understanding them tells you immediately which files will shrink.
The first is backward references. The compressor scans forward keeping a window of recently seen data, and whenever the upcoming bytes repeat something already in that window, it replaces them with a short instruction: go back this far, copy this many bytes. A document that uses the word “information” two hundred times stores it once and refers back to it. This is why text, source code, logs, CSV and XML compress so dramatically: they are full of repeated words, repeated tag names, repeated indentation and repeated structure.
The second is entropy coding. After the references are found, the remaining symbols are re-encoded so that common ones get short bit patterns and rare ones get long patterns, rather than every byte occupying the same eight bits. In English text, the letter e is far more common than the letter q, so giving them equal space wastes room.
Both stages need the same thing to work: predictability. Data that is highly repetitive or highly skewed compresses well. Data that looks random does not, and cannot, regardless of the algorithm.
Why your photos and videos do not shrink
This follows directly, and it is the single most useful thing to take away.
JPEG, MP3, MP4, PNG and most modern formats are already compressed, often aggressively. Their encoders have already found and removed the redundancy DEFLATE looks for. What remains is close to incompressible, not because it is truly random but because all the easily exploitable structure has been spent.
Feed a general-purpose compressor a folder of holiday photos and it will work hard, read every byte, and hand back a file that is a fraction of a percent smaller. Feed it a folder of log files and it may return a tenth of the size. Neither result says anything about the tool.
The practical consequence is that “zip it before sending” is good advice for documents, code and data, and near-pointless for media. If a video needs to be smaller, that is a job for the video encoder, not the archiver.
Compression level is the other half of that decision. Levels run from 0, meaning store, up to 9, meaning try hardest, and the relationship between effort and reward is steeply diminishing. Going from the default to maximum typically buys a small percentage for a large multiple of the time. Our zip creation tool exposes that scale directly rather than hiding it, because the right choice genuinely depends on your content: maximum is worth it for a large text corpus and a waste on anything already compressed.
Zip, tar.gz and 7z solve the same problem differently
The formats people meet are not competing implementations of one idea. They make different structural choices.
Zip compresses each file independently and keeps a central directory at the end listing every entry and where it starts. That index is what allows a tool to extract one file from a thousand without touching the rest, and it is why zip has always been the format for things you dip into.
The Unix convention stacks two tools instead. Tar concatenates files into one stream with a header before each, and performs no compression at all. Gzip then compresses that entire stream as a single unit. Because the compressor sees all the files at once, redundancy between files is available to it, so a hundred similar small files compress far better than they would individually. The price is that there is no index: extracting anything means decompressing from the beginning.
That structural difference is visible in the tooling. Our tar.gz extractor has to walk the stream reading each 512-byte header in turn to find where files begin and end, including a size field written in ASCII octal rather than decimal, which is the classic trap for anyone implementing tar from a half-remembered description. There is no directory to consult because the format does not have one.
7-Zip’s format takes the solid-block idea further and pairs it with a stronger algorithm, LZMA, which uses a much larger window for backward references. A bigger window finds matches that are further apart, so it does better on large archives with distant repetition. It costs more memory and more time, which is exactly the trade it is offering. Our 7z extractor exists because that format is common for large downloads and is one of the ones a fresh machine cannot open without installing something.
The size check has to happen before decompression
Compression ratios cut both ways, and this is where an archive stops being merely inefficient and becomes hostile.
A file consisting of the same byte repeated is astonishingly compressible. A carefully constructed archive can be a few megabytes on disk and expand to terabytes, and nested archives multiply the effect. This is a zip bomb, and it is not a theoretical exercise: it is a real denial-of-service technique against anything that unpacks untrusted archives.
The defence is ordering. A zip’s central directory records the uncompressed size of every entry before any decompression happens, so those declared figures can be summed and checked first. Extracting a zip refuses an archive whose declared total exceeds what a browser tab can safely hold, and it does so before inflating a single byte. Checking during decompression is too late, because by then the memory is already being consumed.
The same check catches the far more common innocent case: a backup or media archive that is simply larger than the available memory. One mechanism, two very different callers.
Verifying that what arrived is what was sent
Compression and integrity are related but separate concerns, and it is worth being precise about which one you have.
Zip stores a CRC-32 checksum per entry, and extractors verify it. That catches accidental corruption: a truncated download, a bad disk sector, a flaky transfer. It does not establish that the archive is the one somebody intended to send you, because anyone who modifies the contents can recompute the CRC, and CRC-32 was never designed to resist that.
For that stronger question you want a cryptographic hash of the file, compared against one published by whoever produced it. Computing a file checksum covers the usual algorithms, and the interesting implementation detail is that it hashes incrementally rather than reading the whole file into memory first, which is what makes it usable on a multi-gigabyte archive inside a browser tab.
Choose the algorithm to match the threat. If you are guarding against accidental corruption and you trust the publisher, any of them works and the fast ones are fine. If an attacker might have substituted the file, MD5 is unsuitable because collisions can be produced deliberately, and a SHA-2 family hash is the right choice.
The short version
Archiving and compressing are separate operations, and store mode exists because sometimes you only want the first one. DEFLATE shrinks data by exploiting repetition, so it transforms text and barely touches media. Zip indexes per file and compresses per file; tar.gz compresses everything as one stream and gives up random access; 7z trades memory and time for a bigger window. And an archive’s declared sizes must be checked before anything is expanded, because the same property that makes compression useful makes a small file capable of filling a disk.
