The block sorting family of compressors barely moved in thirty years. A single block stopped at a few hundred kilobytes, one round used one thread, and code lengths had to be whole bytes. BZip3 opens all of that up at once: blocks reach 511 MiB, the whole pipeline is new, and parallelism comes almost for free.

Loosening the block boundary

Lossless compression has always been an open trade. Smaller output usually costs time and memory. BZip3 is a command line compressor aimed at text and source code, with a compression library written in C alongside it. Its first dial is how far the program can look at once: block size runs from 1 MiB to 511 MiB, with 16 MiB as the default. A larger block gives long range repetition a better chance of being caught, and the ratio follows. The price is spelled out in the documentation. Both compression and decompression need memory roughly six times the block size, and the amount decompression will need is fixed the moment compression runs, so the target machine has to be checked before the dial is touched.

A pipeline stacked from three stages

The pipeline has three stages. The entrance is preprocessing, where run length coding and a Lempel-Ziv predictor each take a pass. The first tidies repeated bytes, the second finds distant identical fragments through LZ77 style string matching and then estimates the next byte with PPM style context modelling. Doing this ahead of the transform strips out long repeats, and the more redundant the material, the larger the gain. The middle is the block sorting transform, built on a suffix array, which gathers similar contexts into neighbouring positions so that the simple low order predictor further down also benefits from high order statistics. The exit is entropy coding: arithmetic coding with zero order context mixing, blending several probability estimates by context, which removes the loss that whole byte code lengths used to impose.

The block ceiling is where the three stages balance out. Feeding the same corpus through different block sizes produces noticeably different ratios, and the official advice is to push the block as high as memory allows, since decompression speed hardly depends on block size at all.

Memory and parallelism handed to the user

Blocks do not depend on each other, so parallelism really is nearly free. The command line takes a worker count, each worker owns one block, the default is a single worker and the ceiling is 64. Four to eight workers in a nightly backup script cuts compression time several times over. Integrity gets no shortcuts either. Every block carries a CRC32 checksum and decompression checks the result byte by byte. Format overhead is 9 bytes per file and 9 to 17 bytes per block, and the project notes that random data typically grows by under 0.8 percent, so incompressible input does not inflate much.

The numbers in the official benchmark

The project publishes a benchmark list that runs material of very different kinds through the compressor. The telling figure is the ratio of compressed size to original size. The bundled source archive goes from 501,760 bytes down to 72,320 bytes, roughly one seventh. A long Chinese text lands at about one sixth. Audio data only reaches about one third, and a virtual machine disk image stops near one half. That is not a universal tool, and the project says so plainly: it is particularly good at text and source code.

Licence, platforms and companion commands

The licence is LGPLv3, with copyright on the runtime code held by Kamila Szewczyk. The runtime library also bundles components under Apache 2.0 and the two clause BSD licence, the build scripts run under GPL three with an Autoconf exception, and the project describes the whole as single licensed under LGPLv3 rather than dual licensed. Platform coverage is wider than expected. The project has tested x86, x86_64, armv6, armv7, aarch64, ppc64le, mips, mips64, sparc and s390x, publishes 32 bit and 64 bit Windows executables plus a 64 bit Linux binary, and can be installed on macOS from a package manager. The options deliberately echo classic Unix compressors: the default action is to compress, -b sets the block size, -j sets the worker count, -d decompresses, -t only verifies, and -B works on a batch. Six companion commands come with the source: bunzip3 for decompression, bz3cat to write output to standard output, bz3grep to search text inside a compressed archive, and bz3less with bz3more and bz3most to page through the decompressed result. Version 1.5.4 was released on 7 September 2026, and the repository has been active since May 2022.

BZip3 does not promise a miracle in compression ratio. What it does is release several limits people had long put up with: blocks grow to 511 MiB, preprocessing gains a predictor, entropy coding becomes context mixing, and parallelism is left to the user to tune. Its natural territory is equally clear: source code, logs and long texts, the kind of material that repeats heavily and cannot afford to lose a single character.