Convert ZIP to BZ2

Very few people choose bzip2 in 2026. They inherit it. A build script from a decade ago pipes through `bunzip2`, a research dataset is published as `.tar.bz2` and the new file has to sit next to the old ones, a mirror's upload rules name the extension, or a tool refuses anything else. Conformance is the entire motivation.

That is a perfectly good reason and this page will not argue with it. What it will do is make sure you are not choosing bzip2 by reputation alone — the reputation was earned around 1996, when it genuinely was the strong option, and the landscape has moved twice since then. If you have a free hand in the matter, read the section on XZ below before you convert anything. If you do not, and the file simply has to match the twelve archives already sitting in that directory, then bzip2 is the right answer and the rest of this page is about what you will actually get back.

The registry describes BZ2 as a stream with exactly one member and lists "no directory structure" among its known problems. It cannot record a file name, let alone a folder tree. That is not a limitation of the implementation; it is what the format is — a compressor, applied to one thing.

So the conversion cannot be a straight repack, and any page implying otherwise is glossing over the interesting part. The ZIP is unpacked, its contents are written into a TAR that carries every name and every path, and bzip2 is applied to that single tarball. Anyone extracting it gets the directory tree back exactly as it was, in two layers that most Unix tools unwrap with one command and most graphical archivers unwrap with two clicks. The arrangement is old enough to predate the format itself, which is why it has a conventional name rather than needing an explanation.

bzip2 does not use a sliding window the way DEFLATE does. It reads a block of up to 900 KB, applies a Burrows–Wheeler transform that sorts rotations of the block so that similar contexts end up adjacent, and then compresses the result. The whole block is the context, not the last 32 KB of it.

That is why it beats gzip on large, repetitive text — log files, XML, CSV exports, source trees — and why the advantage shrinks to nothing at all on a ZIP full of JPEGs or MP4s. Already-compressed data has no remaining structure to sort, so the transform is expensive to run and returns nothing for the expense. Before converting, it is worth glancing at what the ZIP actually holds: the format's one genuine strength applies to roughly half the archives people own, and on the other half you are choosing a slow compressor for no reason at all.

Sorting is not free, and bzip2 is the slow one of the three Unix compressors both at pack time and, more surprisingly to people, at unpack time. Every block has to be un-sorted to be read, which is real work rather than a stream copy.

On the 25 MB the free tier accepts, none of that is noticeable — the job is a couple of seconds either way. It becomes the deciding factor at gigabyte scale, which is exactly the scale at which the old advice to prefer bzip2 was formed, and exactly where xz has since overtaken it on both axes.

Formats on this site carry a status, and BZ2 is the only archive format here marked legacy rather than current. That is a judgement about where it sits in 2026, not about whether it works: bzip2 is stable, ubiquitous on Unix, actively packaged and perfectly safe to use on an archive you are handed today.

It is legacy because both of its neighbours are better at the thing it was chosen for. XZ compresses harder with a dictionary up to 64 MB and decompresses faster than bzip2 does; gzip is faster than both and installed everywhere. That leaves bzip2 occupying a middle ground nobody needs to be in unless an existing file already lives there.

A gzip stream can carry the original name and timestamp of what it compressed. A bzip2 stream carries neither — it is bytes in, compressed bytes out, with a header that says only how big the blocks are. That difference has a practical edge to it.

It means the file name you keep is the only label the archive has from the outside, so a `.bz2` renamed carelessly is genuinely ambiguous about whether it holds a tarball or a single compressed file. Naming the download `something.tar.bz2` rather than `something.bz2` is not pedantry here; it is the only place that information can live.

bzip2 compresses each block on its own, which has two useful consequences. Damage is contained: a corrupted block costs you that block rather than everything after it, and recovery tools exist that pull the intact blocks out of a damaged file.

Independence is also why parallel implementations exist and work well — the blocks can be handed to different cores without coordination. Neither property applies to a solid 7Z archive, where one stream carries everything and a bad byte early on can take the rest with it. If durability matters more to you than ratio, that is a real argument in bzip2's favour.

This conversion runs on our converter rather than in the page. The archive is uploaded over an encrypted connection, 7-Zip unpacks it, the contents are tarred, bzip2 is applied to the tarball, and the result comes back to you. Everything written during the job is deleted when it ends and the working space is memory-backed rather than a disk.

The rules that come with that: 25 MB per file free, sixty seconds before a job is killed, and an outright refusal for an archive that declares an unpacked size above 2 GB. Password-protected ZIPs fail with a message rather than hanging, since the unpacker is called with an empty password on purpose so that it reports rather than waits.

If the archive is going to a person, stop here. Windows Explorer and the macOS Finder both open ZIP with nothing installed, and neither has the faintest idea what a `.tar.bz2` is; the recipient would need bzip2 or a third-party archiver, and then a second step to get past the tar inside. Converting for somebody who did not specifically ask for bzip2 turns a double-click into a support conversation, and you will be the support.

The same holds for most web upload forms, learning platforms and ticketing systems, which accept ZIP and quietly reject everything else on extension alone. Reach for this pair only when a machine at the far end asks for bzip2 by name, or when a dataset's existing files all carry that extension and the new one has to match. Everywhere else, the ZIP you already have is the better file, and the conversion is simply work that makes the situation slightly worse.

The download arrives with your original stem and a `.bz2` extension, so `records.zip` comes back as `records.bz2` even though the bytes are a tarball wrapped in bzip2. Because the format stores no name of its own, the file name is the only description the archive carries, and renaming it to `records.tar.bz2` — or `records.tbz2`, the shorter spelling of the same thing — is genuinely load-bearing rather than cosmetic.

Unwrapping runs in the same two stages. `tar -xjf` handles both layers in one command on any Unix machine, while a graphical archiver on Windows will usually decompress the bzip2 layer first and show you a single `.tar` to open next. That intermediate step is the structure working as designed, not a sign that the conversion produced something odd, and it is the single most common reason people believe a bz2 archive is broken when it is not.