Convert BZ2 to ZIP

Nobody starts a new project with bzip2 in 2026 — our registry marks the format legacy, the only archive format here that carries that status. What exists is history: research datasets published when bzip2 was the strong option, source releases from the mid-2000s, mirrors that never changed their pipeline, backups from a server that has long since been retired.

So the reader of this page is rarely choosing a format. They have been handed one, often a decade after it was written, and the only real question in front of them is how to see what is inside it. That framing matters, because most of the usual advice about compression trade-offs is irrelevant when the file already exists — nobody is deciding between bzip2 and xz here, they are deciding between opening the archive and not opening it. The compression argument only becomes relevant again at the end of this page, for the small number of readers who turn out to be the ones publishing the thing.

BZ2 compresses a single stream. Our registry records it as a stream format with exactly one member and lists the absence of directory structure among its known problems — there is no field in a bzip2 file for a name, a path, a mode or a timestamp.

Everything you think of as the archive is therefore in the TAR underneath: header blocks naming each file, contents in sequence, no compression of its own and no index anywhere. bzip2 sees one long byte stream and never learns that it contains files at all. Unwrapping both layers is what turns the download back into a directory, and doing only the first is what leaves people convinced the archive is broken. The same structure produces `.tar.gz` and `.tar.xz`, so anything you learn here transfers directly to the other two extensions you will meet in the same corners of the internet.

A gzip header can carry the original file name of what was compressed. A bzip2 header carries nothing of the kind — just enough to say how big the blocks are. That difference is invisible until something tries to work out what it just decompressed.

The first version of this converter did exactly that, checking the extracted item for a `.tar` name before unwrapping it again. It worked for gzip, whose header supplied the name, and failed silently for bzip2 and xz, which supply none: the same tar arrived under an anonymous name, the check missed it, and the conversion produced an archive holding one opaque blob instead of the files that went in. It now forces the tar type on the content rather than trusting a name, which is why this page can promise both layers come off.

bzip2 works by reading blocks of up to 900 KB, sorting rotations of each block with a Burrows–Wheeler transform so that similar contexts sit next to each other, and compressing the result. The whole block is the context. ZIP deflates each file separately against a 32 KB window and starts fresh at every entry.

On the material that ends up in a `.tar.bz2` — corpora, logs, source trees, XML, tabular exports — that is a real gap, and the ZIP will be visibly bigger. On an archive of images or video the two are close, because there was nothing left to compress before either of them touched it. If size matters to you more than compatibility does, the answer is to leave the archive as it is and install a tool that reads it, because every format a stock desktop opens compresses more weakly than the one you already have.

Most compressors decompress far faster than they compress. bzip2 is the exception people meet: reversing the block sort is genuine computation rather than a stream copy, so unpacking is slow in a way gzip and xz are not.

Within the 25 MB the free tier accepts, this amounts to a second or two and is invisible. It is nonetheless the reason the format lost its place: xz decompresses faster and compresses harder, which left bzip2 without an argument on either axis and explains why so few archives written in the last decade use it. The one thing bzip2 still does better than either neighbour is contain damage, and that is a durability argument rather than a performance one — which is why the format survives in archival corners and nowhere else.

One thing bzip2 genuinely does well is contain damage. Each block is compressed on its own, so a corrupted region costs you that block rather than everything after it, and recovery tools exist that pull the intact blocks out of a broken file.

That is worth knowing before you convert an old archive that has been sitting on failing storage. If the conversion fails here, the archive may still be partly recoverable locally with a bzip2 recovery tool, and that is a better next step than uploading it repeatedly. A conversion needs a whole, readable archive; salvage needs a different tool.

Not every bzip2 file is a tarball. A single compressed database dump, one big log, one exported table — bzip2 applied to one file is the format used exactly as intended, and no TAR is involved.

The converter tries to read the decompressed content as a TAR and, when that fails, treats it as the one file it is. You get a ZIP containing that file. The only cost of the ambiguity falls on the name: because bzip2 stored none, the entry inside the ZIP is named from the pipeline rather than from anything the archive remembered.

This pair does not run in your browser — unwrapping and rewriting archives needs real programs. The file is uploaded over an encrypted connection to our converter, decompressed, unwrapped, packed as a ZIP and returned. Everything the job wrote, including the intermediate tar, is deleted when it finishes.

The working directory is memory-backed with a fixed size and is thrown away with the container. Free uploads stop at 25 MB, jobs are killed at sixty seconds, and an archive that declares more than 2 GB of contents is refused before extraction begins. If the archive is confidential rather than merely old, 7-Zip and Keka do the same job offline.

Readers of this page sometimes turn out to be the custodian rather than the recipient — the person who has inherited the download everyone else is struggling with, and who can change what is published next time. In that case the useful output of this conversion is not the ZIP but the decision it prompts, because every future reader will otherwise repeat the search that brought you here.

For an audience that unpacks in a shell, `.tar.xz` compresses better than bzip2 and decompresses considerably faster, and every relevant machine already has it. For an audience on desktops, a ZIP is the file that opens with no instructions attached. Publishing both is not indecision; they are two audiences with genuinely different tools, the archive costs almost nothing to produce twice, and continuing to ship only bzip2 serves neither group particularly well.

Archives that reach this page are often old, and old files have usually been copied between machines several times. Before assuming a conversion failure is our problem, it is worth testing the archive where it sits: `bzip2 -t` verifies the compressed stream without writing anything, and any archiver will report a checksum mismatch rather than handing over damaged content, because bzip2 stores a CRC for every block and one for the whole file.

If that test fails, the conversion here will fail too, and repeated uploads will not change the answer. What can change it is a recovery tool that walks the file block by block and salvages the intact ones — practical precisely because bzip2 compresses each block independently. Recover first, convert second. A converter needs a whole, readable archive; salvaging a damaged one is a different job for a different program, and doing them in the wrong order wastes an afternoon.