Convert TAR to BZ2

Almost everyone arriving here was told to. A package recipe lists `.tar.bz2` in its sources and computes a hash against it. A project’s release process has produced that extension since 2006 and the download page, the mirrors and the third-party build scripts all point at it. A university or government deposit specifies the format in a submission checklist. An old distribution’s upload tooling accepts it and nothing newer.

None of those are going to change for one archive, and none of them are wrong to resist changing — an artefact name is part of a contract that other people have built against. That makes this a compliance conversion, and it deserves to be framed as one rather than dressed up as an optimisation. If you are choosing freely and nothing downstream cares, the honest recommendation on this page is to close it and pick gzip for speed or XZ for size.

Bzip2, from 1996, does something structurally different from both of its neighbours. It cuts the input into blocks of up to 900 KB and applies a Burrows–Wheeler transform to each one, which reorders the bytes so that identical contexts end up adjacent. A move-to-front pass and Huffman coding then squeeze the resulting runs. It is not a sliding-window compressor at all.

The registry records the 900 KB block as its window, and that number is the fair comparison against gzip’s 32 KB: within a block, bzip2 sees far more context than gzip ever can, which is why it wins on text. It is also the fair comparison against XZ’s 64 MB dictionary, which is where bzip2 loses — a 900 KB block cannot notice that a file at the start of the archive resembles one at the end. Bzip2 sits precisely between them, and being in the middle is why it has been squeezed out.

Compression is slow because the sort is expensive, and that is the part you pay for once, on a machine that is not waiting for you. It is bearable. Decompression is the surprise: undoing a block sort is real work, unlike undoing a sliding-window match, so bzip2 is far slower to unpack than gzip and slower than xz too.

This is what makes the format a poor choice for anything fetched and unpacked repeatedly. A dependency downloaded on every CI run, a container layer, an artefact pulled by a hundred machines — every one of them pays the decompression cost every time, and it is measured in minutes on a large archive rather than seconds. Bzip2 is tolerable for something written once and read once. It is genuinely expensive for something written once and read continually.

Memory at decompression. Bzip2 works in blocks of at most 900 KB, so the buffer it needs to unpack anything is small and fixed no matter how large the archive is. XZ needs memory scaled to the dictionary the file was written with, which the registry records at up to 64 MB — and if the machine cannot provide it, the archive does not open at all.

That matters in a narrower set of places than it used to, but the places are real: routers and embedded appliances, memory-capped containers, recovery environments, an initramfs, an old system nobody is allowed to upgrade. If the archive has to be unpacked somewhere like that, bzip2 is a defensible engineering choice rather than a legacy habit, and it is worth writing down why in the release notes so the next person does not "fix" it.

BZ2 compresses exactly one stream. It has no field for a file name, no notion of a directory and no way to mark where one member ends and the next begins — the registry lists the absence of directory structure as a known problem for the format. Everything a listing of a `.tar.bz2` shows you is being read out of the TAR inside it.

So the conversion unpacks whatever you sent, writes a fresh TAR from the contents, and compresses that with bzip2. The tarball is built from inside the extracted directory, so your files sit at the top level rather than inside a wrapper folder. The download arrives with a `.bz2` extension and should be renamed to `.tar.bz2`, which is both accurate and the form that lets `tar xjf` do the whole job in one command.

Bzip2’s blocks are compressed independently of each other, which gives the format a property its neighbours do not have: damage to one block does not necessarily destroy everything after it. Tools exist that walk a corrupted bzip2 file, find the intact block boundaries and recover what is still readable.

Treat that as a consolation rather than a strategy. The TAR inside is a continuous stream of headers and data, so recovering some blocks and not others gives you a tarball with holes in it, and whether that yields usable files depends entirely on where the damage fell. If surviving bit rot is an actual requirement, the answer is a format with per-member checksums and separate parity, not a compressor with a helpful failure mode.

The conversion does not wrap bzip2 around the file you uploaded. It extracts the TAR and writes a new one, then compresses that. The files inside are byte for byte identical — this is a lossless repack — but the archive around them is new, and member ordering, recorded timestamps and permission bits may differ from what you sent.

For the packaging reader that is the detail that decides whether this tool is the right one. If the recipe checks a hash of the artefact, the artefact has to be produced deterministically on a machine you control, with `tar --sort=name --mtime=…` and `bzip2` doing the work. Use this converter when you need a `.tar.bz2` to exist — for a mirror, a colleague, an upload form, a test — and not when the exact bytes are part of the contract.

On our server, not in your browser. Many tools on this site convert on your own device and say so; archive work is one of the exceptions, because it needs real programs. The file goes over an encrypted connection to a container running 7-Zip and bzip2, and that container has no outbound internet access of its own.

Every job gets a scratch directory on a memory-backed filesystem which is thrown away as soon as the job ends, successful or not, and any job still running after sixty seconds is killed. That timeout is more likely to be reached here than on most pairs, because bzip2 compression is slow — a large tarball of text is exactly the input that takes its time. The free tier accepts 25 MB per uploaded file.

The only honest ratio figure is the one measured on your data, and getting it takes two minutes: compress the same TAR as GZ, as BZ2 and as XZ and put the three sizes side by side. On a source tree or a set of logs the ordering will be predictable — XZ smallest, BZ2 next, GZ largest — but the gaps vary enormously with the contents, and on a tarball of already-compressed files all three land within a rounding error of each other.

Then weigh the numbers you cannot see in a file listing. How often will this be unpacked, and by what? Gzip if the answer is "constantly, by machines". XZ if the answer is "almost never, by a normal computer". BZ2 if something specified it, or if the machine at the far end has very little memory. Choosing bzip2 for its compression ratio alone is a decision that made sense twenty years ago and has quietly stopped being true.