I run ezyZip, a browser-based archive tool, so "which format should I use?" is a question I field constantly. The honest answer is usually "it depends," which satisfies nobody. So I stopped hand-waving and measured it.
We benchmarked 42 archive and compression formats, spanning four decades, from 1984's Unix compress through today's Zstandard, Brotli, and context-mixing paq8px. Everything ran against the same realistic 55 MB corpus, every archive was round-trip verified byte for byte, and the whole thing reproduces from a single command. Here's what came out of it, and what I'd actually reach for.
The setup
Most compression benchmarks measure raw codecs on standardized corpora like Silesia. That's the right call for algorithm research and the wrong call for answering "what should I zip my folder with?" I wanted end-user formats, real CLI tools, container overhead and all, on data that looks like an actual folder.
So the corpus is deliberately mixed: about 11 MB of text, 15 MB of office documents, 16 MB of images, and 13 MB of video, all public domain so it can be committed and redistributed. That mix matters. Office documents (.docx, .xlsx, .pptx) are themselves ZIP containers, so they stress how a tool handles already-compressed data. The JPEG and H.264 media is near-incompressible and sets an honest lower bound. The plain text and uncompressed images are where formats actually separate.
Two rules kept it fair and practical:
- Only two levels per tool: its default, and its one "maximum compression" dial. No method tuning, no dictionary sizes, no thread-count games. That's what a normal person can reach.
- Everything is round-trip verified. Each archive gets extracted, and every file is hashed with SHA-256 against the original manifest. Exit codes are not trusted. That last rule earned its keep immediately.
The verification gotcha
On the image category, a 1985-era ARC build produced an archive that its own extractor happily unpacked, while printing a CRC warning and emitting a file 55 bytes longer than the original. Exit status: success. If I had trusted the tool's own report, a silent corruption would have sailed through as a passing result.
This is the part I'd carry into any benchmark you write: verify content, not exit codes. A bug shared between a compressor and its matching decompressor will happily mask itself. Wherever possible I cross-checked with an independent extractor, so the tool that wrote the archive isn't also the one grading it.
To keep results byte-reproducible across machines, single-stream tools (gzip, xz, zstd, and friends) compress a canonical tar: entries sorted by name, zeroed ownership, fixed timestamps. Otherwise your filesystem metadata leaks into the archive size and nobody can reproduce your numbers.
The results
Full corpus, ranked by ratio (archive size as a percentage of the original, lower is better). This is a slice; the full 58-row table is in the writeup linked at the bottom.
| Format | Level | Ratio | Compress (s) | Decompress (s) | Note |
|---|---|---|---|---|---|
| zpaq | max | 56.11% | 144.4 | 149.9 | smallest, but slow and niche |
| 7z (LZMA2) | max | 59.96% | 4.43 | 0.43 | best mainstream ratio |
| tar.xz (LZMA2) | max | 59.98% | 13.5 | 0.60 | |
| tar.zst (Zstandard) | max | 61.33% | 6.82 | 0.05 | near-instant decompress |
| tar.br (Brotli) | default | 65.00% | 84.0 | 0.23 | slow encode |
| RAR 5 | max | 78.09% | 1.02 | 0.20 | |
| ZIP (Info-ZIP) | max | 81.87% | 1.50 | 0.32 | opens everywhere |
| tar.gz (gzip) | max | 81.92% | 1.50 | 0.10 | |
| tar.zst (Zstandard) | default | 82.44% | 0.08 | 0.05 | fastest useful default |
| tar.lz4 (LZ4) | max | 84.45% | 0.39 | 0.05 | speed over ratio |
| tar (uncompressed) | default | 100.03% | 0.06 | 0.05 | baseline |
| ARC (SEA, 1985) | default | 113.11% | 1.33 | 0.26 | expanded the data |
The frontier is steep and then flat. Moving from gzip to xz or 7-Zip buys a big ratio win for a modest time cost. Pushing past that, into zpaq max or paq8px, buys a few more points at one to three orders of magnitude more time.
What I'd actually use
For most work, two formats cover it, and I think that's the best default precisely because it's boring and predictable.
- ZIP for anything you hand to another person or system. Every OS and language has opened it natively for thirty years. If interop matters more than bytes, this is the best choice, full stop.
7-Zip or xz when size matters. On the full corpus, 7-Zip hit 60% in about four seconds versus ZIP's 82%. A quarter smaller for no perceptible effort.
A few developer-specific notes from the data:Zstandard is the sweet spot for artifacts and pipelines. Its default level compresses in a blink and decompresses in 0.05s, which is exactly what you want for build caches, CI artifacts, and anything you unpack often. Turn the dial to
--ultra -22and it competes with 7-Zip on ratio.Zipping media is pointless for size. Every format landed at 98 to 100% on the video category, some slightly larger from container overhead. If you need a smaller video you re-encode it; you don't wrap it in an archive. Same story for JPEGs.
-
Office documents are already ZIPs. Plain ZIP left them at 99%. 7-Zip, working across archive members, got them to 60%.
The exotic tail isn't worth it
paq8px compressed the text category to 17.8%, the smallest single number anywhere in the study. It also took the better part of twenty minutes for 11 MB and produces a file only paq8px can read. zpaq reached 56% on the full corpus but ran ~150 seconds each way, against 7-Zip's four.
Meanwhile plain ZIP hit 35% on text, and the 1993 PKZIP 2.04g binary I ran under DOS emulation produced a nearly identical 35.5%. The ZIP a casual user gets today is essentially the one from three decades ago. Past the mainstream tools, you pay large time and compatibility costs for small size gains.
The longevity finding
This one surprised me most, and it's an engineering lesson more than a compression one.
Every vintage format from 1985 onward still round-trips cleanly once its tool is rebuilt from source: ARC, zoo, LHA, ARJ, HA, freeze. A 1993 PKZIP binary, run under DOSBox, still emits a ZIP that modern unzip opens.
The Windows-only archivers of the 2000s fared worse. FreeArc and UHARC, run under Wine with Rosetta 2 on Apple Silicon, consistently deadlocked in their compression cores under x86-to-ARM binary translation. ACE creation is only available through a discontinued graphical installer. A 40-year-old open DOS format proved more durable than a 20-year-old proprietary Windows one.
If you archive anything for the long term, that's the takeaway: simple, open, well-documented formats outlast the software that made them. Pick accordingly.
Reproducibility
The entire study runs from one command that verifies the corpus, runs the benchmark, and regenerates the tables and figures:
./run_all.sh
The corpus and every raw per-run JSON result are committed, so any number can be re-derived without sitting through the multi-hour run.
The short version
The best way to compress a file in 2026 is refreshingly dull: ZIP to share, 7-Zip or Zstandard to shrink, and don't bother zipping media. The exotic tail is fascinating, and most of it still works, some of it heroically, but it offers ordinary use little the mainstream doesn't, at costs you shouldn't pay.
I wrote a longer, less technical walkthrough with all 58 results and the full story here: The Best Way to Zip a File in 2026.
What do you reach for, and has anyone found a case where the exotic formats actually paid off? I'm curious where my "not worth it" holds up.
Top comments (0)