Convert XZ to BZ2

This conversion has one honest justification and it is worth putting first, because every general comparison of the two formats says to do the opposite. XZ decompression allocates a dictionary-sized buffer, and the registry records the format’s dictionary at up to 64 MB. On a laptop that is invisible. On a consumer router flashing a firmware bundle, inside a container with a 32 MB memory limit, in an initramfs or a rescue shell, or on an old commercial Unix box with a conservative per-process limit, it is the difference between the archive opening and the extractor being killed.

The second version of the same problem is that xz is simply not installed. It arrived in 2009, which is recent enough that plenty of long-lived systems — appliances, instruments, industrial controllers, a build image somebody froze — have bzip2 and gzip and nothing newer. Adding a binary to a machine like that is often impossible for reasons that have nothing to do with technology. Converting the archive is the change you are allowed to make.

XZ, from 2009, is LZMA2: a sliding-window compressor with a dictionary the registry records at up to 64 MB. Compressing byte one hundred million, it can still see byte thirty-six million, which is why it notices that a file at the end of an archive resembles one at the start. To decompress it, the reader has to keep that same window available, because any back-reference may point anywhere inside it.

BZ2, from 1996, does not slide at all. It cuts the input into blocks of up to 900 KB, sorts each one with a Burrows–Wheeler transform, and codes the result. A block is self-contained, so the decompressor holds one block and nothing else. That design decision is why bzip2 loses on ratio — it cannot see past 900 KB — and it is exactly the same decision that makes it cheap to unpack. The two properties are the same fact viewed from either end.

The size penalty is real and its scale depends entirely on the contents. On a source tree, a corpus of documents, log files or anything else with structure repeating across many members, XZ will have found a great deal that bzip2 cannot, and the BZ2 will be visibly larger. That is the price of the memory saving and there is no way to avoid paying it.

On other archives the penalty rounds to nothing. If the XZ holds photographs, video, audio or an already-compressed database dump, the strong compressor never had anything to work with; both formats are essentially just wrapping the data, and the two files land within a few percent of each other. Look at the two numbers before you commit to anything downstream — this is one of the few conversions where the answer varies by an order of magnitude between one archive and the next.

It is easy to assume the weaker format is faster at everything and that is not what happens. XZ is slow to compress, because searching a 64 MB dictionary is expensive, and comparatively quick to decompress, because following a back-reference is close to a memory copy. Bzip2 is the other way round in a way that matters: undoing a Burrows–Wheeler transform is genuine computation, so bzip2 unpacks slowly.

That is worth planning around, because it partly undercuts the reason for the conversion. A constrained device now needs less memory and more time, and if it is also a slow processor — which small devices usually are — the extraction can take considerably longer than the XZ would have. Memory is the constraint that makes a job impossible; time is the one that makes it annoying. Convert when the first applies, and measure the second before promising anyone a number.

Both are single-stream compressors and neither knows what a file is. The registry lists the absence of directory structure as a known problem for both, which is why both are almost always found with a TAR inside them. This conversion unwraps the tarball out of the XZ and writes a new one before compressing it with bzip2.

Neither format records an original file name — gzip does, and these two do not — so the extension you put on the download is the only label the file will ever carry. Call it `.tar.bz2`. The same nameless property caused a real defect in this converter, since the inner tarball arrives from an XZ called whatever the extractor chose rather than something recognisable; the code now forces the tar type instead of guessing from the name, which is why an xz source is unwrapped correctly today.

Bounded memory is the headline, and there is a second consequence that suits the same reader. Because bzip2’s blocks are compressed independently, a damaged file does not necessarily lose everything after the damage — recovery tools can find the intact block boundaries and salvage what survives. A truncated or corrupted xz stream generally ends there.

That fits the environments this page is written for, which are also the environments where storage is cheap flash of uncertain quality, power is cut without warning, and there is rarely a second copy nearby. It is not a backup strategy and should not be sold as one: the TAR inside is a continuous stream, so recovering some blocks yields a tarball with holes in it and what you get out depends on where the damage landed. It is simply a better failure mode than the alternative.

If the reason for leaving XZ is memory or a missing binary, gzip solves both at least as well and costs less time. It needs a 32 KB window — nothing at all — it is present on effectively every system that has any compressor whatsoever, and it decompresses far faster than bzip2 on the slow processors these devices tend to have. The only thing it gives up is ratio, and it gives up more of it than bzip2 does.

So the case for bzip2 specifically is narrow: the size difference between gzip and bzip2 genuinely matters for your transfer or your flash budget, and the extra decompression time is affordable. If it does not matter, gzip is the better target and the conversion is available on this site as well. Being told which of two pages to use is more useful than being sold the one you happened to land on.

On our server rather than in your browser. Most tools here run on your own device and say so plainly; archive repacking is one of the exceptions, because it needs 7-Zip and bzip2 as real programs. The file goes over an encrypted connection to a container that runs them, and that container has no outbound internet access of its own.

Each job gets a scratch directory on a memory-backed filesystem, which is deleted the moment the job ends whatever the outcome, and any job still running after sixty seconds is killed. Both halves of this pair are slow — xz to unpack a large dictionary and bzip2 to compress — so the timeout is closer than on most pairs. The free tier accepts 25 MB per uploaded file, and the archive is refused before extraction if it declares an expansion above 2 GB.

The only verification that means anything here is done on the target. Copy the BZ2 to the device, appliance or container that failed on the xz file and extract it there — not on your workstation, where both formats would have worked and you would learn nothing. If bzip2 is also missing, you have found that out for the cost of a file transfer rather than in the middle of a deployment.

Then compare the listing against the original: `tar tJf` on the XZ and `tar tjf` on the BZ2 should show the same count and the same paths. This is a lossless repack, so a difference is never a damaged file — it is a structural one, usually a leading directory that is present in one and absent in the other. Once the listings agree and the target machine has unpacked the result, the XZ can go.