The Hidden Tradeoffs of Compression in .NET: ZIP vs 7-Zip vs Zstandard

Compression isn’t just about squeezing files into a smaller size. It’s about speed, compatibility, storage cost, and how your tooling fits into the bigger picture. And if you’re working with .NET, picking the wrong algorithm can quietly wreck your CI/CD speed, your artifact performance, or even your deployment reliability.

I ran a benchmark recently comparing three heavyweights: ZIP, 7-Zip (LZMA2), and Zstandard (zstd). The dataset? 5.4GB of actual .NET publish output across microservices. Real files. Real builds. No synthetic fluff.

Let’s walk through what actually matters and how to make the right call for your use case.

First, why this even matters

.NET publish folders aren’t light. You’ve got DLLs, JSON, config, binaries. Multiply that across services and environments, and you’re dealing with a lot of repeat data. Which means compression plays a key role in:

• CI/CD build pipelines
• Docker image layering
• Cloud artifact storage
• Deployment packaging
• Backup archives

If compression slows down every build or bloats your backups, it adds up. Not just in time… but in dollars too.

Here’s who’s competing

ZIP
Built-in. Basic. Compatible with everything. Uses Deflate. Not the best at shrinking file sizes, but it works anywhere.

7-Zip (LZMA2)
If you want to squeeze every last byte out, this is the one. It’s slower than molasses when using Ultra settings, but nothing else gets files this small.

Zstandard (zstd)
Fast. Balanced. And surprisingly powerful. Built by Facebook for high-performance systems. Great compression speeds and consistent decompression times across all levels.

Now the test results

I compressed the full dataset using all three formats. Didn’t test decompression time in this run, but I’ll talk about that in a second.

Here’s what stood out.

7-Zip (Ultra preset)
✔ Shrunk the dataset by 84%
✘ Took forever to do it
✅ Great for offline use, backups, cold storage
✘ Definitely not for fast CI/CD workflows

Zstandard (preset 6 + dictionary)
✔ Cut size down by ~70%
✔ Compressed the whole thing in 1 minute
✔ Decompression is lightning fast
✅ This is the sweet spot for pipelines, runtime downloads, and Docker layers

ZIP
✔ Compatible with everything
✘ Weakest compression by far
✅ Still makes sense if your hands are tied (legacy systems, embedded scripts, etc.)

Let’s talk decompression

No benchmark is complete without this angle.

Here’s what you need to know:

• Zstandard is 5–10x faster at decompressing than 7-Zip
• It’s consistent, even when heavily compressed
• 7-Zip slows down with solid blocks and larger dictionaries
• ZIP sits in the middle, but it’s just… basic

So if you’re extracting on-the-fly (updaters, deployment scripts, containers), decompression speed could make or break the experience.

Want to run your own test? Here’s how

Use this stack:

• System.IO.Compression or zstdsharp in .NET for actual file handling
• Stopwatch for timing
• perfmon (Windows) or iotop (Linux) for disk activity
• Add memory usage tracking (LZMA2 gets hungry)
• Multi-threading? Definitely test with different core counts, zstd and LZMA2 scale very differently

If you’re benchmarking CLI tools, I recommend Hyperfine. Super clean results.

My compression cheat sheet

Final thoughts

Here’s the bottom line:

• If you want the smallest size, use 7-Zip
• If you need speed and balance, go Zstandard
• If you’re stuck with legacy tools, stick with ZIP

No single option wins across the board.

Each one has a role. You just need to pick the right one for your workflow.

Want to see the full table with compression sizes, times, and settings? It’s all laid out right here. If you’re into compression benchmarks, server setups, or software engineering workflows, hasto.pl has a solid library of step-by-step guides built for developers and tech professionals.

Try it out for yourself and see what makes sense in your setup.