DevTools•Jun 2026•3 min read

Xz vs Zip

Xz crushes harder and slower; Zip is the universal envelope everyone already opens. They solve different problems, so the verdict turns on whether you control both ends of the pipe.

The short answer

Xz over Zip for most cases. For the job people actually reach for these tools — shipping large artifacts, tarballs, backups, and distro packages where you control decompression — Xz wins.

  • Pick Xz if control both ends, ship big artifacts or tarballs, and want the smallest possible file with strong LZMA2 ratios
  • Pick Zip if handing a file to a stranger, a Windows user, or anything that must double-click open with zero tooling
  • Also consider: Zstd if you want most of Xz's ratio at a fraction of the CPU — the modern default for new pipelines.

— Nice Pick, opinionated tool recommendations

What they actually are

Xz is a compressor — a single-file stream codec built on LZMA2, the same engine behind 7-Zip's heavy lifting. It does one thing: squeeze bytes. It is not an archiver; it compresses one stream, which is why you always see it bolted onto tar as .tar.xz. Zip is the opposite animal: an archive format AND a compressor in one, descended from PKZIP in 1989, using DEFLATE by default. Zip bundles many files plus metadata into one container that anything — Windows Explorer, macOS Finder, every language's stdlib — can crack open without a second thought. So comparing them is slightly unfair: Xz makes files small, Zip makes files portable and self-contained. The question is never 'which compresses better in a vacuum,' it's 'do you need a universal envelope or a tighter squeeze.' Pretending they're interchangeable is how people end up shipping a .tar.xz to a confused marketing team.

Compression ratio and speed

On ratio, Xz wins and it isn't close. LZMA2 at -9 routinely beats Zip's DEFLATE by 20-40% on source code, logs, and text-heavy payloads — sometimes more. That's why kernel.org, GNU, and most distros ship .tar.xz: bandwidth and mirror storage at scale make every percent matter. The catch is cost. Xz at high levels is gluttonous — slow and memory-hungry, with -9 wanting hundreds of MB of RAM to decompress, which has bitten embedded and CI environments. Zip's DEFLATE is ancient, fast, and cheap, with a 64KB window that caps how clever it can get. It compresses in a blink and decompresses faster, but leaves real space on the table. If your bottleneck is disk or transfer, Xz pays you back. If it's CPU time or a low-memory target, Zip's mediocrity is at least predictable and quick. Neither is the speed king anymore — Zstd ate that crown.

Compatibility and ecosystem

This is Zip's entire case, and it's a strong one. Zip is everywhere by default: Windows and macOS open it natively, every programming language ships a zip module, and no recipient ever asks 'what do I do with this.' That ubiquity makes Zip the correct choice the moment a human you don't control is on the receiving end. Xz needs tooling. Plain Windows won't open a .xz without 7-Zip or similar, and a bare .xz is a single compressed stream — to bundle a directory you must tar first, which trips up anyone who lives outside Unix. On Linux/macOS dev boxes, xz is preinstalled and frictionless, so among engineers it's a non-issue. But Zip carries metadata, random per-file access, and self-extraction that a tar.xz can't match without unpacking the whole thing. Compatibility is boring, and Zip is gloriously boring — which is exactly why it refuses to die.

Security and integrity

Both ship integrity checks — Xz uses CRC32/CRC64/SHA-256 per block, Zip uses CRC32 — so silent corruption is caught either way. But Xz carries a fresh scar: the 2024 xz-utils backdoor (CVE-2024-3094), where a malicious maintainer slipped a sshd-targeting backdoor into the upstream library. That was a supply-chain compromise, not a flaw in the format itself, and the codec is fine — but it's a reminder that 'fewer eyes, deeper trust' is a real risk surface. Zip's weak spot is its encryption: legacy ZipCrypto is trivially broken and should never be used; only AES-256 Zip (WinZip/7-Zip) is acceptable, and support for it is inconsistent across tools. Neither format is an encryption product — if you need real confidentiality, reach for age, GPG, or transport-layer crypto and stop asking your compressor to moonlight as a vault. For plain integrity, both are adequate; for secrecy, both are the wrong tool.

Quick Comparison

FactorXzZip
Compression ratioLZMA2, typically 20-40% smaller on text/sourceDEFLATE with 64KB window, decent but dated
Speed & memorySlow and RAM-hungry at -9Fast, cheap, predictable
Out-of-box compatibilityNeeds 7-Zip on Windows; must tar to bundle dirsOpens natively everywhere, self-contained archive
Archive features (multi-file, random access)Single stream only; tar handles bundlingNative multi-file container with per-file access
Standard for large source/distro artifactsDe facto choice (kernel.org, GNU, distros)Rare for tarball-style distribution

The Verdict

Use Xz if: You control both ends, ship big artifacts or tarballs, and want the smallest possible file with strong LZMA2 ratios.

Use Zip if: You're handing a file to a stranger, a Windows user, or anything that must double-click open with zero tooling.

Consider: Zstd if you want most of Xz's ratio at a fraction of the CPU — the modern default for new pipelines.

Xz vs Zip: FAQ

Is Xz or Zip better?

Xz is the Nice Pick. For the job people actually reach for these tools — shipping large artifacts, tarballs, backups, and distro packages where you control decompression — Xz wins on raw ratio and is the de facto standard for source archives. Zip wins compatibility, but compatibility is a default, not an achievement.

When should you use Xz?

You control both ends, ship big artifacts or tarballs, and want the smallest possible file with strong LZMA2 ratios.

When should you use Zip?

You're handing a file to a stranger, a Windows user, or anything that must double-click open with zero tooling.

What's the main difference between Xz and Zip?

Xz crushes harder and slower; Zip is the universal envelope everyone already opens. They solve different problems, so the verdict turns on whether you control both ends of the pipe.

How do Xz and Zip compare on compression ratio?

Xz: LZMA2, typically 20-40% smaller on text/source. Zip: DEFLATE with 64KB window, decent but dated. Xz wins here.

Are there alternatives to consider beyond Xz and Zip?

Zstd if you want most of Xz's ratio at a fraction of the CPU — the modern default for new pipelines.

🧊
The Bottom Line
Xz wins

For the job people actually reach for these tools — shipping large artifacts, tarballs, backups, and distro packages where you control decompression — Xz wins on raw ratio and is the de facto standard for source archives. Zip wins compatibility, but compatibility is a default, not an achievement.

Related Comparisons

Disagree? nice@nicepick.dev