Convert XZ to TAR.BZ2 Online (LZMA2 Re-Compressed With Burrows-Wheeler bzip2)

Two Different Compression Algorithms, Same Uncompressed Tarball

A .tar.xz file and a .tar.bz2 file usually hold identical contents packaged the exact same way — files and folders bundled by TAR with their Unix permissions and structure preserved — and differ only in which compression algorithm was applied afterward. XZ uses LZMA2, released in its stable .xz container form in December 2008 by the Tukaani project. TAR.BZ2 uses bzip2, a considerably older algorithm written by Julian Seward and first released in 1996, more than a decade before XZ existed.

Converting XZ to TAR.BZ2 means decompressing the LZMA2 layer to recover the plain tarball, then recompressing that same tarball with bzip2 instead. Nothing about the files inside changes — every filename, folder, and permission bit carries through — but the compressed bytes on disk are produced by a fundamentally different algorithm working on the same input data.

The naming itself reflects two separate steps bundled into one filename. TAR handles bundling: it walks a directory tree and writes every file's name, owner, permission bits, and raw content into one continuous stream with no compression of its own. Whatever comes after the second dot in ".tar.xz" or ".tar.bz2" only describes which algorithm shrank that already-bundled stream afterward, and swapping XZ for bzip2 changes nothing about how that bundling step happened in the first place.

Dictionary Matching Against Burrows-Wheeler Block Sorting

LZMA2, the algorithm inside XZ, works by finding repeated sequences of bytes across a sliding dictionary window and replacing them with shorter references back to where that sequence appeared earlier, then running the result through range coding, a form of entropy coding related to arithmetic coding that packs the output even tighter. This dictionary can be sized up to a large maximum depending on the compression level chosen, letting LZMA2 spot repetition across a wide span of the file.

Bzip2 takes a completely different approach. It splits data into blocks of up to 900 KB, then applies the Burrows-Wheeler transform, which rearranges the bytes within each block into runs that are far more repetitive than the original ordering, followed by a move-to-front transform and Huffman coding to compress those runs. Because bzip2's transform operates on fixed-size blocks rather than a sliding dictionary that can span the whole file, it tends to lose ground to LZMA2 on data with long-range repetition, which is one concrete, technical reason XZ generally outcompresses bzip2 on the same input rather than the two simply being "different flavors of the same idea."

Both algorithms follow their main compression step with entropy coding, but even that final stage differs — LZMA2 uses range coding, while bzip2 finishes with Huffman coding after its move-to-front step. Huffman coding assigns shorter binary codes to more frequent symbols and is generally simpler and faster to run than range coding, which is one more small piece of why bzip2 tends to complete faster than XZ even before accounting for the dictionary-size difference between the two approaches.

What Switching From LZMA2 to Burrows-Wheeler Actually Changes

• Lose — XZ's typically smaller output on most data: LZMA2's sliding-dictionary approach generally out-compresses bzip2's block-based Burrows-Wheeler transform on the same content, so the resulting .tar.bz2 is often larger than the original .tar.xz was.
• Gain — faster compression at comparable settings: bzip2 is widely reported as quicker to compress with than XZ, especially at XZ's higher, slower presets, trading some final size for less waiting.
• Gain — a format some older toolchains specifically expect: certain older build systems, patch-distribution scripts, and package formats standardized on bzip2 before XZ existed and still default to it.
• Unchanged — every file and Unix permission inside the tarball: the underlying TAR archive structure passes through both the decompression and the recompression step completely intact.
• Lose — the CRC64 default integrity check XZ carries: bzip2 archives don't carry the same optional CRC64 check XZ defaults to; bzip2 relies on its own internal block-level CRC32 instead.

Where TAR.BZ2 Still Shows Up in Real Software Distribution

Despite XZ's compression advantage, bzip2 hasn't disappeared from real distribution pipelines. Older Linux kernel mirrors kept offering .tar.bz2 tarballs for years after .tar.xz became available, and kernel.org only stopped generating anything besides XZ-compressed tarballs for its main pub locations on September 1, 2018 — meaning .tar.bz2 kernel releases were an actively supported, commonly downloaded option for years into the .xz era, not a format abandoned the moment its replacement showed up. Some Python source distributions, patch archives, and specific package-manager ecosystems built around bzip2 in the 1990s and 2000s also continued shipping it as a default or fallback option well after XZ existed, simply because switching a long-established build pipeline carries its own cost independent of which algorithm compresses smaller.

Every major current Linux distribution, macOS, and Windows (through 7-Zip or similar third-party tools) reads both .tar.xz and .tar.bz2 without issue today, so compatibility in the sense of "will this file open" is rarely the real concern for anyone choosing between them now — the actual decision usually comes down to whether the extra compression time XZ takes at higher settings is worth the smaller resulting file for a specific build or release pipeline.

The command-line tools themselves also differ slightly in how they're invoked: bzip2 exposes compression levels 1 through 9 controlling block size, with 9 as the common default, while xz exposes levels 0 through 9 with an additional "extreme" variant at several levels that spends more time searching for matches in exchange for marginally better compression. Anyone scripting a build pipeline that currently calls bzip2 directly needs to update those specific command flags when switching to xz, since the two tools don't share flag syntax even though both wrap the same conceptual job of shrinking a tarball.

The Actual Complaint Behind "Bzip2 Archives Are Too Slow to Build"

A specific, recurring complaint in build-pipeline discussions isn't that bzip2 fails to compress a tarball, but that continuous integration jobs and package-build scripts using it take longer overall than expected once bzip2's per-block processing overhead is added up across a large number of files, especially on CI runners with limited CPU allocation. This is a real, measurable throughput issue rather than a format defect, and the documented fix reported across build-tooling forums is simply switching the build step to a faster algorithm — sometimes gzip for speed, sometimes XZ at a lower preset for a middle ground — rather than trying to tune bzip2 itself, since its block size and transform behavior offer limited room for speed adjustment compared to LZMA2's configurable dictionary size and preset levels.

A second real issue shows up around large files with very long repeated sequences, such as disk images or database dumps, where bzip2's 900 KB block ceiling caps how far back it can find repetition, producing a noticeably worse compression ratio than XZ manages on the exact same file. This isn't a bug either; it's a direct, structural consequence of bzip2 processing data in bounded blocks rather than across a much larger sliding dictionary the way LZMA2 does, and it's specifically why bzip2 tends to lose more ground to XZ on large, highly repetitive files than it does on smaller, more varied ones.

LZMA2 Dictionary Compression Against Burrows-Wheeler Block Sorting

Questions About Swapping Compression Algorithms on the Same Archive

Will my .tar.bz2 file be bigger than the .tar.xz version was?
Usually yes. LZMA2's sliding-dictionary approach in XZ generally compresses better than bzip2's block-based Burrows-Wheeler transform on the same data, so recompressing with bzip2 typically produces a somewhat larger file.

Is bzip2 an outdated format I should avoid?
Not outdated in the sense of being broken or unsupported — every current major operating system reads it fine. It's simply an older algorithm from 1996 that generally trades some compression ratio for faster compression speed compared to XZ.

Why did Linux kernel downloads offer .tar.bz2 for so long after .tar.xz existed?
Kernel.org kept both options available for years, only moving to XZ-exclusive tarballs on its main download locations on September 1, 2018, giving existing scripts and users a long transition window rather than an abrupt cutover.

Does converting between these two change any files inside the archive?
No. The TAR structure, filenames, folder layout, and Unix permission bits pass through unchanged; only the compression algorithm wrapping that structure is different between the two.

Which one should I pick for a new backup script?
If final file size matters most and the extra compression time is acceptable, XZ generally wins. If the archive needs to be created quickly and repeatedly, such as in a fast-running CI job, bzip2's shorter compression time is often the more practical choice.