Short answer: for the smallest file, use xz -6; for the fastest compression, use gzip -9. I compressed the same 40.7 MB file with gzip, bzip2 and xz on Linux, twice each, and timed decompression too. xz produced the smallest archive (34.9% of the original size), gzip was 6.6 times faster than xz, and bzip2 landed in the middle on size while being the slowest to decompress by far. If you only remember one rule: xz for archives you keep, gzip for files you send.
How I Tested
Every compression comparison has the same flaw: the test file. A file of repeated text compresses beautifully with everything; a file of random data compresses with nothing. So I used real files — the documentation tree on this machine (/usr/share/doc), packed into a single 40.69 MB tar archive, excluding files that were already gzip-compressed (.gz changelogs would have skewed the ratios, since no tool can squeeze an already-compressed file further).
The four contenders:
- gzip -9 — the default Linux compressor, maximum level
- bzip2 -9 — the older block-sorting compressor, maximum level
- xz -6 — the LZMA2 compressor at its default level
- xz -9 — xz at its maximum level, to see what the extra effort buys
Each compression ran twice and I report the average time; decompression ran once per format, output discarded. Test machine: Ubuntu 24.04, 2 vCPUs, with gzip 1.12, bzip2 1.0.8 and xz (XZ Utils) 5.4.5. All tests ran on 2026-10-24.
The Results
| Tool | Compressed size | % of original | Smaller by | Compress time | Decompress time |
|---|---|---|---|---|---|
| gzip -9 | 17,549,975 bytes | 41.1% | 58.9% | 2.56 s | 0.34 s |
| bzip2 -9 | 16,206,222 bytes | 38.0% | 62.0% | 5.60 s | 2.34 s |
| xz -6 | 14,907,272 bytes | 34.9% | 65.1% | 16.82 s | 0.34 s |
| xz -9 | 14,744,340 bytes | 34.6% | 65.4% | 18.80 s | 0.34 s |
Three things stand out.
1. xz wins on size, but -9 is barely better than -6. xz at its default level shrank the file to 34.9% of its original size — 16% smaller than gzip's output. Pushing xz to maximum level (-9) saved only another 162,932 bytes, a 1.1% improvement, while taking 12% longer. On a 40 MB file that difference is trivial; on a 40 GB backup it is still only about 400 MB. Unless you are archiving at serious scale, xz -6 is the sweet spot and -9 is not worth the wait.
2. gzip is in a different league on speed. gzip compressed the file in 2.56 seconds — 2.2 times faster than bzip2 and 6.6 times faster than xz -6. If you are compressing logs on a server, packaging a release, or shrinking something before uploading it, gzip's 58.9% reduction at that speed is hard to argue with. The extra 6 percentage points xz buys cost you 14 extra seconds on a small file, and that gap scales with file size.
3. bzip2 is the worst of both worlds in this test. It neither compresses the most (xz beats it by 8%) nor the fastest (gzip beats it by 2.2x) — and its decompression is the real surprise: 2.34 seconds versus 0.34 seconds for both gzip and xz, nearly 7 times slower. That matters more than it sounds. You compress a file once but you may decompress it dozens of times, on machines you do not control. A format that is slow in both directions needs a special reason to choose, and in 2026 I could not find one in this test: bzip2's only remaining advantage is compatibility with very old systems.
One more number worth noting: xz decompresses as fast as gzip. The old worry that "the strongest compression is painful to unpack" does not apply to xz — its decompression is a different, much cheaper operation than its compression. So the xz archive you store today costs you nothing extra when you need the files back.
The Exact Commands
Replace file with your file or directory. For a directory, tar it first — the compressors below work on single files, which is why .tar.gz and .tar.xz are two-step formats.
Smallest archive (my recommendation for storage):
tar -cf archive.tar directory/
xz -6 archive.tar
# produces archive.tar.xz — unpack with: tar -xf archive.tar.xz
Fastest compression (my recommendation for sending):
tar -czf archive.tar.gz directory/
# the -z flag does gzip in one step — unpack with: tar -xzf archive.tar.gz
If you must use bzip2 (for example, a legacy pipeline expects .bz2):
tar -cjf archive.tar.bz2 directory/
To check what you would get before committing, compress to stdout and measure without writing a file: xz -6 -c file | wc -c gives the compressed byte count directly.
Which Tool Should You Use?
- Archiving backups, releases, or anything you will store: xz -6. Smallest files, fast decompression, and it is preinstalled on every major Linux distribution.
- Compressing something to send or upload right now: gzip -9 (or plain
tar -czf). The file is a bit bigger, but it is ready in seconds and anything can open it. - A script that runs on unknown or very old machines: gzip. It is everywhere, including minimal containers and embedded systems where xz may be missing.
- Starting a new project in 2026: do not pick bzip2. It loses on size to xz and on speed to gzip, and it is the slowest to decompress. Keep it only for compatibility with existing
.bz2workflows.
A note on what I did not test: zstd, the newer Facebook compressor, was not installed on this machine, so it gets no numbers here — only tools I actually ran appear in the table. zstd's reputation is "near-gzip speed with near-xz size," which would make it a strong contender, but reputation is not a test result, so it stays out of the verdict until I can run it.
FAQ
Does the compression level matter much for gzip?
Less than you might think. gzip -9 versus the default -6 typically saves only a few percent on text, and costs a little extra time. If you are scripting, plain gzip (level 6) is fine; I used -9 here to give gzip its best possible showing, and xz still won on size.
Why is xz -9 barely better than xz -6? Higher xz levels mostly increase the dictionary size and search effort, which helps on large, repetitive data. On mixed real-world text like documentation, the default level already captures most of the patterns. Diminishing returns kick in fast — that is the same reason gzip -9 barely beats gzip -6.
Can Windows or macOS open .tar.xz files?
Yes. 7-Zip on Windows and The Unarchiver (or tar itself) on macOS handle .tar.xz without fuss. gzip's .tar.gz remains the most universal format of all, which is part of why it still wins the "just send it" category.
Is bzip2 dead?
Not dead — it is still maintained and perfectly functional. But "functional" is not "best," and no result in this test gives a new project a reason to choose it over xz or gzip. Existing .bz2 files are fine; there is no need to convert them.
Conclusion
On real documentation files, xz -6 is the best compressor for storage (65.1% smaller, fast decompression), gzip -9 is the best for speed (2.56 seconds, 58.9% smaller), and bzip2 finishes last on both counts — including a decompression time nearly 7 times slower than the other two. Pick xz when the file will sit on a disk, gzip when the file needs to move, and stop reaching for bzip2 out of habit.
How this article was made
Corpus built 2026-10-24 with tar --exclude='*.gz' -cf corpus.tar /usr/share/doc (42,670,080 bytes, 40.69 MiB) on Ubuntu 24.04. Compression commands run twice each (gzip -9 -c, bzip2 -9 -c, xz -6 -c, xz -9 -c); times averaged from the two runs; decompression timed once per format to stdout discard. Tool versions: gzip 1.12, bzip2 1.0.8, xz (XZ Utils) 5.4.5. No external benchmarks were used — every number in the table comes from these runs. This article was drafted with AI assistance; every number, timing, and command result comes from the author's own test runs on that date.