ZIP vs 7Z vs ZSTD: The definitive comparison with real-world data

Choosing between ZIP, 7Z, and ZSTD seems like a minor issue until you need to deploy applications, send daily backups, or reduce storage and bandwidth costs (see how to compress and decompress files ). In practice, the decision affects delivery times, CPU/RAM usage, and even compatibility with third-party tools and systems.

After reviewing multiple benchmarks with real data and very different contexts — from a 5,4 GB .NET dataset for deployments, to a 1 GB Wikipedia text corpus , to container images and a 28,7 GB binary — the complete picture reveals when to prioritize ratio, where decompression speed rules , and what implications compatibility has (classic ZIP, ZIP with ZSTD, 7Z with LZMA2 or with alternative codecs, etc.).

What we compare and why it matters

We analyzed the most commonly used archive families: ZIP (Deflate) , 7Z (LZMA/LZMA2) , and ZSTD . Brotli, XZ, bzip2, zpaq, and LZ4 are also included in the discussion because, in real-world scenarios, it's rarely a straightforward head-to-head comparison. In .NET deployments, for example, the balance between compatibility, throughput, and speed is weighted differently than in bulk backups or distribution package packaging.

Context matters: if you're looking for minimal deployment time and ubiquitous support, your choices aren't the same as when you're trying to minimize the storage of 15 backups (and split compressed files ) and optimize egress costs. The good news is that there are now comparable figures and clear patterns to help you make informed decisions.

How each format works (and what it means in practice)

• ZIP (Deflate) It combines LZ77 and Huffman; it's the veteran, ubiquitous, and completely compatible. It doesn't usually win in compression ratio or speed compared to modern options, but opens anywhere (see how manage browser extensions) and its implementation is stable and well-known. Traditional ZIP (method 8) had historical limitations, although modern compressors overcome many of these constraints.
• 7Z It relies mainly on LZMA/LZMA2, with a very good ratio and mature tools. In addition, 7-Zip parallelizes well and its "sensible defaults» make you feel agile. It's a de facto standard in desktop and dev environments, with broad support in Windows, Linux and macOS (sometimes using external utilities).
• Zstandard (ZSTD), created by Facebook (2015), stands out for extremely rapid decompression and a very wide level palette (1–22). Its goal is to perform as well as or better than Deflate and come close to LZMA in ratio, with generally faster execution. We see it integrated into BSD/Linux kernels, packet compression (e.g. Arch Linux uses zstd level 20, decompressing 14x faster than XZ with just +0,8% size) and increasingly present in CI/CD pipelines.

Other actors worth knowing

• Brotli, designed for the Web, compresses better than gzip on textual content and benefits from the content-encoding of browsers. Its compression benchmark is single-threaded, which skews time comparisons. real wall-clock if you're dealing with multi-threaded codecs, but there are parallel implementations. In server environments, power consumption Total CPU (user+sys) is more relevant than the wall clock.
• XZ Improves LZMA and offers great ratio at the expense of high compression times. For large binaries, it can be competitive, but its decompression speed often falls behind ZSTD and 7Z. Multithreaded concurrency and the parameter -e (extreme) They improve the photo somewhat, although they do not work miracles.
• bzip2/pbzip2 They balance ratio and CPU more or less in the middle of the board. With pbzip2 parallelism is gained. However, for many modern cases ZSTD and 7Z offer better trade-offs global
• zpaq is he "all-terrain vehicle with the maximum ratio» with journaling type incremental compression; its focus is on squeezing bytes, gladly sacrificing the decompression speedFor cold backups, this might be a good idea; for general use, it isn't.

Benchmarks with data: text, large binaries, and deployments

1) Textual dataset (Wikipedia 1 GB)

In a comparison of ZIP (via 7zip), 7zip, XZ, Brotli, Zstandard, and zpaq on 1 GB of Wikipedia text, time versus size was plotted at each level. The author notes: these are non-scientific tests, and Brotli's single-threaded reference penalizes the "real-world" times. In user+sys computing, the picture improves for Brotli; ZSTD appears very competitive, decompressing extremely quickly and achieving ratios comparable to XZ/7zip under heavy load.

Key findings: ZIP lags behind in compression ratio and time; 7zip advances with more refined tools and multithreading; XZ improves ratio but decompresses slower than ZSTD; ZSTD balances fantastically when increasing effort; and zpaq achieves top ratios at the cost of significant time, especially in decompression.

2) PeaZip "maximum compression" test (Windows, i7-8565U)

Using PeaZip/WinRAR, input file size 303,0 MB and five repetitions per test, these were the average values ​​(sizes in MB; times in s):

Conclusions: ZPAQ wins in pure compression ratio but is very slow, even when extracting. 7Z (LZMA2) offers a good compression ratio, with reasonable extraction. Using Brotli/ZSTD within 7Z makes extraction incredibly fast (Brotli even faster), in exchange for longer compression times than LZMA2 at ultra settings. RAR prioritizes compression speed, sacrificing some compression ratio, and if you need security, you can learn how to password-protect compressed files.

3) Huge 28,7GB binary (Linux, Ryzen 5 5600G)

On a 28,65–28,7 GB file, the goal was to compress it as much as possible and compare ratios and times with xz, pbzip2, 7z and zstd :

• xz -9e -T12: 12,6 GiB in ~15m49s (≈ 44,0%)
• pbzip2 -9: 13,07 GiB in ~4m29s (≈ 44,55%)
• 7z -mx=9: 12,9 GiB in ~16m43s (≈ 43,98%)
• zstd –ultra -22 -T12: 12,48 GiB in ~19m48s (≈ 43,57%)

In "maximum compression," ZSTD narrowly won in size , but took longer. pbzip2 surprised with its speed, achieving a similar ratio. This case illustrates that, with very large binaries, absolute differences in GB are as significant as CPU usage in minutes, and it's worthwhile to quantify both.

4) Game ZIPs (EU4) and converting from tar+brotli to ZIP with ZSTD

A real-world example: EU4 saves arrive as poorly compressed ZIPs. Extracting and recompressing were tested: rezipping saves approximately 17%. Changing the codec within the ZIP file resulted in the following improvements per level:

Furthermore, the Wasm payloads for transcoding are: ZSTD ~215 kB (136 kB if only the encoder), Brotli ~683 kB . In parsing, taking into account fetch time from the cache ( the browser's Brotli content-encoding is not free), ZSTD and Brotli performed very similarly: Brotli parses slightly faster because it doesn't decompress into user space; ZSTD benefits from not touching the content-encoding and reads more efficiently from the disk.

With an upload speed of 30 Mb/s, integrating transcoding + transfer in a typical 7,7 MB ZIP: original 2,05 s; ZSTD-3 1,70 s; ZSTD-5 1,88 s; ZSTD-7 2,28 s. The practical recommendation leaned towards ZSTD level 7 for storage savings (when you pay for the bucket), although level 3 is tempting if latency is your priority.

5) .NET Deployments (5,4 GB publish)

In a case of deploying .NET applications with 5,4 GB of output (a mix of self-contained and framework-dependent), the practical guide is clear: choose based on your objective . If you're aiming for universal compatibility, go with classic ZIP; if the bottleneck is decompression and speed , ZSTD is a strong contender; if you want a high throughput ratio with a well-established CLI and tooling, 7Z with LZMA2 remains the winning choice.

Decompression: the most noticeable factor in the experience

Several independent tests point to ZSTD as being in a class of its own when it comes to decompression. In the text benchmark, looking at user+sys makes it clear why ZSTD is optimal for file system compression (see how to disable automatic compression ) and package wrapping: reading is fast and the CPU cost is low. 7-Zip offers a very good experience, and the difference with XZ is explained more by utilities and multithreading than by codec magic.

ZIP surprised everyone in user+sys decompression metrics, performing better than expected; if your target audience has modest machines or workflows where fast extraction is paramount, don't dismiss it without testing. ZPAQ , meanwhile, reminds us of its limitations: incredible efficiency, but very long extraction times , suitable for cold backups.

Use cases: How to decide with data (RAM, time, ratio, and cost)

In a container platform scenario where daily backups of 30–100 containers are required , the operating budget is paramount. A pragmatic scoring system was proposed:

• RAM: Target 200 MB compression and 100 MB decompression to score 5; for every 50 MB or more, subtract 1 point.
• Time: 3-hour daily window to compress everything; per container, 6–1,8 minutes. On the scale, >120 s scores 0, every -20 s adds 1, <10 s is 5 points in decompression.
• Ratio: With ~1,6GB objects (e.g. MariaDB+PHP+WordPress), and ~$6/TB storage on Backblaze/E2 type backends, aiming for ≥4:1 helps to get the results down. cost of egress (be careful with AWS at $0,09/GB outgoing).

Testing levels, ZSTD level 3 achieved approximately 3,5:1 in about 3 seconds with 207 MB of RAM; Brotli level 6 reached approximately 4,3:1 in about 30 seconds with a good RAM profile. Adjusting ZSTD's tuning (strategy, searchLog, targetLength, minMatch) didn't improve performance enough without penalizing time or memory; in that specific analysis, Brotli level 6 emerged as the favorite. Interestingly, Brotli level 4 used more memory than levels 3 and 5 but matched the level 5 ratio in half the time, a very attractive option if the extra 13 MB of storage is acceptable.

If the objective changes (e.g., rapid deployments or intensive reading), the weights vary, and ZSTD tends to be the most balanced choice due to its lightning-fast decompression and decent ratios at mid-levels.

Compatibility, support, and the role of ZIP with ZSTD

A key point: the ZIP standard incorporated ZSTD (method 93) starting with specification 6.3.8 (2020). This allows for " good old-fashioned ZIP " with a modern codec. How well is the ecosystem supporting it? Currently, Windows Explorer doesn't create or extract ZIP files using ZSTD; mainstream 7-Zip is integrating it, and there are already working forks. On Linux, there are forks of p7zip. The situation is improving, but some friction remains.

If you use Total Commander, you can enable 7z reading with ZSTD by replacing the TCLZMA64.DLL by compatible versions (e.g., the TotalCmd.7z package from 7-Zip ZS). To create 7z files with ZSTD within TC, older plugins do not always respect the chosen codec and fall back to LZMA; it is better to use 7-Zip ZS complete or the Codecs plugin on an existing 7-Zip installation. With 7-Zip ZS you'll have compression/downloading of Brotli, LZ4, Lizard, ZSTD inside the 7z container and handling ZIP+ZSTD. Check with 7z i which codecs are active.

In web browsers and pipelines, Brotli's content encoding seems like a "totally free" solution, but there are nuances: middleware, proxies, and frameworks (e.g., discrepancies between debug/production modes in Next.js) can redo compression or add latency. Serving pre-compressed files isn't always straightforward either (Cloudflare Pages doesn't support it out of the box). In several real-world cases, replacing streams with ZSTD in ZIP format and decompression in user space resulted in fewer environment dependencies and equivalent or better results.

Useful parameters and recommended levels

In ZSTD , levels 3, 5, and 7 offer good operating points. A study comparing transcoding and transfer at 30 Mb/s showed level 3 as the fastest end-to-end, but level 7 saved storage (in EU4, 12,5% ​​less than level 5 and 25% less than level 3). AWS Athena documents a preference for levels 6–9 when level 3 is not used by default, which aligns with this finding.

The temptation to enable long-distance matching is real, but beware: it requires that the decompressor has the same amount of memory as the compressor. In deployments and client apps , this requirement can be impractical. It's better to keep windows and tables within reasonable budgets.

In Brotli , the key adjustment is usually the level . Changing lgwin can increase memory without significant gains if you're already at a high level. The observation that level 4 matches the ratio of level 5 in half the time—at the cost of slightly more RAM—is invaluable when you want to lower latency without significantly increasing memory size.

For XZ , the -e flag applies slower variations of the preset, aiming for a slightly higher ratio. The manual tables remind us that the compressor's memory usage increases, but the decompressor 's remains the same. Even so, compared to ZSTD, XZ often suffers in decompression when the goal is to open packets at high speed.

If you rely on classic ZIP but want the maximum speed of Deflate, libraries like libdeflate significantly improve throughput compared to zlib. In the Rust ecosystem, zip-rs doesn't yet facilitate switching backends when creating ZIPs, so this approach may not be available without additional work.

Related articles:

How to speed up file transfers in Windows 11: key tricks and tweaks