I Benchmarked 42 Compression Formats Spanning Four Decades. Here's What to Actually Use.

Andrew Dyster — Fri, 10 Jul 2026 15:41:42 +0000

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 -22 and 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.

Built P2P file transfer tool for browsers

Andrew Dyster — Sun, 17 Aug 2025 03:15:54 +0000

Hey everyone,

I've been running ezyZip (a file compression site) for a while, and users kept asking for a way to share large files without the hassle of cloud storage. So I built a P2P transfer feature that works differently from WeTransfer and similar services.

How it works:

Drag and drop your files onto ezyZip File Transfer app
Get a link like ezy.zip/ABCDE
Your files transfer directly from your browser to the recipient's browser
Cloudflare handles the WebRTC signaling to connect you - the actual files never touch any server

The technical bit:

It's quite simple: Just static HTML/JS files using WebRTC for peer-to-peer connections. Cloudflare handles the signaling server part to establish connections between browsers. Files get compressed into a ZIP on the fly, then stream directly to whoever has your link. Since there's no server storage, there's no file size limit except your patience and bandwidth.

Why I think this is better:

Privacy - Files never sit on someone else's server
Speed - Direct transfer is often faster than upload then download
No infrastructure costs - It's just static files plus Cloudflare for signaling
Free - Minimal costs means I can keep it free without limits (There is a 1gb limit just because it needs to hold all the file data in memory)

You do need to keep your browser tab open while the other person downloads. But you get live progress updates, and once they're done, the link's ready for the next person.

Should work with modern browsers (tested on Chrome)

Try it out: https://www.ezyzip.com/share-files-en.html

DEV Community: Andrew Dyster