Een ZIP-bestand comprimeren (en wanneer herverpakken loont)

What "compressing a ZIP" actually means

A ZIP archive is not one big compressed blob. It is a container of entries, and every entry — every file inside — is compressed on its own. Each one is either stored, meaning its bytes were copied in unchanged, or deflated, meaning they were run through the Deflate algorithm first. The archive's size is simply the sum of those entries plus a little container overhead per entry: a local header, a line in the central directory at the end, the filename written twice. That per-entry independence is the single most useful fact about the format, because it means the question "will this ZIP shrink?" is really many small questions — one per file inside.

Deflate itself does two things. It looks back over the bytes it has already seen for repeated sequences and replaces each repeat with a short back-reference — "the same 58 bytes as 2,000 bytes ago" — and then it encodes what remains so that frequent bytes cost fewer bits than rare ones. The levels 0 through 9 that every ZIP tool exposes are not different formats; they are an effort dial on that same search. A higher level looks harder and longer for better back-references. Crucially, every level produces a standard Deflate stream, every level is completely lossless, and any unzipper ever written can open the result — a ZIP packed at level 9 is exactly as compatible as one packed at level 1.

Recompressing a ZIP, then, is a straightforward mechanical pass: read each entry, decompress it back to its exact original bytes, and compress those bytes again at the level you chose, writing a fresh archive. Nothing about your files changes — not their content, not their names, not the folder structure. The only thing that changes is how efficiently the container wraps them. If the original archive left space on the table, the pass reclaims it; if the original was already packed tightly, the pass proves it and gets out of the way.

Why would an archive leave space on the table? Because most ZIPs are created by whatever wrote them fastest. Operating systems' built-in "compressed folder" features favour speed over size. Export functions in apps frequently store files with no compression at all, because writing is quicker that way and nobody was watching the output size. Build systems and download portals routinely ship ZIPs at low levels for the same reason. None of that is wrong — it was the right trade at creation time. But it means that a deliberate second pass at level 9, made when size finally matters, very often finds real savings that the first, hurried pass never looked for.

Why text shrinks and photos refuse: a little entropy

Compression is the removal of predictability. Anything with structure — repetition, patterns, a limited alphabet — can be described more briefly than it is written, and that briefer description is the compressed file. Plain text is enormously predictable: the same words, tags and phrases recur constantly. So are CSV exports, JSON, XML, log files and source code, which repeat field names, keywords and indentation thousands of times. Deflate feasts on this. Folders of that kind of content routinely come out 60–80% smaller, and a database dump or a log directory can do even better. If your ZIP is full of text, repacking it at a high level is close to free money.

The same logic covers a less obvious family: uncompressed media formats. A BMP image is raw pixel rows; a WAV file is raw audio samples; an uncompressed TIFF is raw scan lines. Nothing has removed their internal redundancy yet — neighbouring pixels resemble each other, silence is long runs of near-identical samples — so Deflate finds plenty to fold away. Archives of BMP screenshots, WAV recordings or raw sensor exports shrink dramatically, often to a fraction of their size, without losing a single sample or pixel.

Now the other side of the ledger. A JPEG, an MP4, an MP3 or a PNG has already been through a compressor, and a compressor's output is deliberately unpredictable — if any pattern remained, the compressor would have removed it. To Deflate, those bytes look like random noise, and random noise cannot be compressed again; that is not a limitation of one tool but a mathematical property of information. Deflate cannot meaningfully compress its own output either, which is why an archive that was already packed at level 6 gains only a sliver from a level 9 repass. Modern office files sit in this camp too: a DOCX, XLSX or PPTX is literally a ZIP archive itself, deflated internally, so a folder of them behaves like a folder of small ZIPs.

Real archives are usually a mix, and the honest way to reason about one is entry by entry: the stored and lightly compressed entries will shrink a lot, the already-compressed entries will barely move, and the total is whatever that blend produces. This is exactly how the tool's own estimate works. Before anything is uploaded, it reads the archive's table of contents in your browser, measures how many bytes are stored versus already deflated, and models the two populations separately — rather than promising you a flattering blended percentage that your particular archive cannot deliver.

The level trade-off: 0, 1, 6 and 9, honestly

The tool's presets map directly onto real Deflate levels, and it is worth knowing exactly which. Maximum compression is level 9 — the smallest archive Deflate can produce. Balanced, the default, is level 6 — the same level most ZIP software uses as its own default, and for good reason. Fast is level 1, the lightest pass that still compresses. No compression is level 0, which repacks every entry as stored. And the Custom preset adds a slider from 0 to 100 that maps onto the full 0–9 range, for the cases in between.

The shape of the curve is the important part, and it is not linear. On typical mixed content, level 1 already does most of the work: stored bytes come out at very roughly 72% of their original size, in a fraction of the time the higher levels need. Level 6 pushes that to around 62% — nearly everything Deflate will ever achieve — while staying quick. Level 9 grinds out the last couple of percent, landing near 60%, and pays for it with substantially more CPU time: expect it to take roughly two to three times as long as Balanced on a large archive. Those numbers move with the content, but the pattern never does — the early levels are cheap and effective, the last level is expensive and marginal.

That pattern makes the choice simple. Balanced is the right answer almost always: near-maximum savings, modest wait. Reach for Maximum compression when the output genuinely earns it — an archive that will be downloaded thousands of times, attached to something with a hard size cap, or archived once and kept for years, where a one-time wait buys a permanent saving. Reach for Fast when the archive is huge and mostly uncompressed — a directory of logs or exports — and you want most of the win right now.

Level 0 deserves a word, because "a compressor that does not compress" sounds absurd until you need it. Storing entries uncompressed makes an archive that opens and extracts as fast as the disk can read, with no decompression work at all — useful for media-heavy bundles that tools will read straight out of the archive, where the contents would not compress anyway and raw speed matters more than a few megabytes. The repack still normalizes the container itself; it just leaves every entry stored.

Integrity: your files come out byte-for-byte identical

The most important property of this whole operation is the one that is easy to take for granted: Deflate is lossless at every level. This is not like compressing a video or a photo, where a smaller file means quality quietly traded away. When an entry is decompressed and recompressed — at level 1, 6 or 9, it makes no difference — extracting it afterwards yields exactly the bytes you started with. Every file, every name, every folder path survives the trip unchanged. The level dial trades your time against archive size, never against your data.

The tool does not merely assume that; it checks. After the repack, the entry count of the new archive is verified against the original before anything is handed back. If they ever disagreed — a wedged stream, a truncated write — the job fails outright rather than delivering an archive that quietly lost something. A failed job costs you a retry; a silently mangled backup can cost you the only copy of a file. The verification exists so the second outcome is impossible.

Timestamps get the same respect. Each entry's modification time is your data — often the only record of when a photo was taken off a camera or a report was generated — so the repack preserves them by default. There is a toggle to discard them if you prefer a normalized archive, but that is a choice you make explicitly; it is never done silently on your behalf.

Finally, the refusals, which are a feature. A password-protected ZIP cannot be read without its password, so the tool rejects it up front with a clear message instead of failing halfway through or, worse, stripping the protection: remove the password with the software that added it, compress, then re-protect the result if you need to. An empty archive is refused too, since there is nothing to compress. And the tool will never hand you a bigger file than you gave it — when an archive is already packed so tightly that the rewrite comes out larger, it ships your original bytes untouched and reports an honest 0%, because a "compressor" that returns a larger file has not compressed anything.

Doing it in the browser: free, no signup, up to 2 GB

The practical part is deliberately boring. The ZIP Compressor runs from your browser, is completely free, and asks for no account, no email and no signup; there is no watermark and no artificial quality cap. It accepts ZIP archives up to 2 GB each — enough for a full project folder, a photo export or a sizeable backup — and up to three archives in one job. A ZIP goes in and a ZIP comes out; the format never changes under you.

Before a single byte leaves your machine, the archive's table of contents is read locally in your browser. That scan is what powers the estimate you see on screen: how many files and folders the archive holds, how much of it is stored versus already deflated, and from that a projected output size and processing time for whichever preset you have selected. It is also where a password-protected archive is flagged immediately, so you find out before uploading two gigabytes, not after. The estimate is computed from your archive's actual composition — the same model described above — which is why it will honestly tell you when there is little to gain.

It is worth being equally plain about what the tool does not do. It compresses ZIP archives and produces ZIP archives — it does not read or create RAR or 7z files, does not convert between archive formats, does not add password protection, and does not split archives into parts. The 7z format's LZMA compression genuinely beats ZIP's Deflate on compressible content, and pretending otherwise would be silly; but ZIP remains the one archive format that opens everywhere — every operating system, every decade-old unzipper, every upload form — with no extra software. That compatibility is usually the reason you have a ZIP in the first place, and it is exactly what a repack preserves.