# BZip3 compression for text and code workloads > BZip3 is a C-based compression project for text, source code, and other compressible data. The README attributes its compression ratio to context mixing, Burrows-Wheeler transformation, and LZ77-style prediction, while documenting substantial memory use and a strict data-loss warning. **iczelia/bzip3** — A better and stronger spiritual successor to BZip2. - Repository: https://github.com/iczelia/bzip3 - Stars: 1,524 · Forks: 66 - Language: C - License: LGPL-3.0 - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/iczelia-bzip3 ## What BZip3 targets BZip3 is positioned as a spiritual successor to BZip2, not as a drop-in replacement for every BZip2 use case. The README says BZip3 excels at compressing text or code, which narrows its intended audience to users managing source archives, documentation, scripts, and other data with repeated symbols and predictable language structure. It is a C project, and the repository includes command-line programs plus headers and examples, so it can also be relevant to software that needs to call a compression library rather than only invoke a binary. The central design goal is compression efficiency, not minimal memory use. The README reports 12,178M of memory for one `bzip3 -e -b 511 -j 4 all.tar` benchmark and 18,301M for `bzip3 -e -b 256 -j 12 all.tar`. Those figures belong to the repository's Perl source archive benchmark, but they establish an important adoption boundary: high-ratio settings may require substantial memory. A user with a small container, an embedded device, or a workstation with limited free RAM should not assume that the headline compression improvements transfer directly to that environment. The project also includes `bz3grep`, `bz3cat`, `bz3less`, `bz3more`, and `bz3most`. Their presence suggests that the distribution covers more than one-shot archive creation. The README does not give a complete command reference for each utility, so their exact option behavior should be checked in the man pages and repository documentation before being placed in a production script. ## How BZip3 compresses data The README identifies three main mechanisms. BZip3 uses an order-0 context mixing entropy coder, a Burrows-Wheeler transform implementation based on suffix arrays, and an RLE with Lempel-Ziv plus prediction pass based on LZ77-style string matching and PPM-style context modeling. This combination is more complex than the pipeline implied by the name alone. The entropy coder models symbols using context, the transform reorganizes the input to expose repetition, and the prediction-oriented pass searches for matches. The repository structure supports this description. `src/` and `include/` contain the implementation and public interfaces, while `examples/` includes programs named `hl-api.c`, `fuzz-round-trip.c`, `fuzz-decode-block.c`, and `fuzz-decompress.c`. The round-trip and decompression examples indicate that the project has a library-facing surface and that decompression paths are distinct enough to have dedicated test programs. They do not, by themselves, prove that every possible input is safe from bugs. The README explicitly warns that special cases in the algorithms leave a low but non-zero possibility of unrecoverable data. The data flow can therefore be summarized as follows. Input passes through the BWT-oriented transform, related predictive passes, and entropy coding to produce a BZip3 archive. Decompression reverses that process through the library or bundled programs. The repository's example archives and test files can be used as development fixtures, but the README does not document a formal compatibility guarantee for every archived file or every BZip3 release. ## Building BZip3 and running the first compression For a source checkout, the README first points to `./bootstrap.sh`, followed by the Autotools-style build sequence. The command below is copied from the project instructions. Run these steps in the repository root unless its build documentation says otherwise. ```console $ ./bootstrap.sh $ ./configure $ make $ sudo make install ``` The last command installs the built program system-wide, so its permissions and destination matter on a shared machine. The README does not document an uninstall command or a package-manager install for Linux distributions beyond pointing to Repology. On macOS, it gives a Homebrew command: ```console $ brew install bzip3 ``` The first real command shown for compression is from the repository benchmark rather than a separate quick-start tutorial. It uses the `bzip3` executable, `-e` for encoding, `-b` to select a block-size setting, and `-j` to select worker threads. This example should not be copied blindly into a small-data workflow because the benchmark uses a large `.tar` file and reports multi-gigabyte memory consumption. ```console % bzip3 -e -b 511 -j 4 all.tar ``` After compression, use the bundled `bunzip3` program for decompression. The README does not state its exact command syntax, so the man page is the appropriate source for that invocation. This absence matters for scripting. A first-use check should create a disposable input file, compress it with a modest documented setting, decompress it with `bunzip3`, and compare the result before using the tool for irreplaceable data. ## Compression ratio against BZip2 and Zstandard The repository's Perl source benchmark reports a substantial difference between `bzip3 -b 511` and the other listed compressors. The README records compressed sizes of 546,456,978 bytes for `bzip3 -b 511`, 1,001,957,587 bytes for `bzip3 -b 256`, 2,056,645,240 bytes for `xz -T16 -9 -k all.tar`, and 3,076,143,660 bytes for `zstd -T12 -16 all.tar`. The same table reports 3,441,163,911 bytes for `bzip2 -9 -k all.tar`. These numbers are a project-published benchmark, not a universal performance guarantee. The input is a combined archive of Perl source `.tar` files, which matches the README's claim that BZip3 is especially suitable for text and code. It does not establish the result for already compressed media, random files, archives with many unique binary records, or workloads where memory and elapsed time matter more than output size. The decompression table reports 4min 06s for BZip3 in parallel, compared with 4min 40s for LZMA, 9min 22s for BZip2, and 3min 51s for Zstandard. The README also says that BZip3 performance depends heavily on the compiler, with x64 Linux clang13 builds reported at up to 17MiB/s compression and 23MiB/s decompression per thread. Windows and 32-bit builds may be considerably slower. A deployment decision should therefore include a local test with the actual compiler, architecture, filesystem, and input distribution. ## Where BZip3 is the wrong choice BZip3 is a poor fit when the operating budget is tight. The benchmark records 18,301M of memory for `bzip3 -e -b 256 -j 12 all.tar`, and 12,178M for `bzip3 -e -b 511 -j 4 all.tar`. Thread count, block size, input size, and compiler implementation can all affect resource requirements, but the published figures are enough to rule out an assumption of negligible memory use. It is also a poor fit for workflows that depend on the mature BZip2 command and archive ecosystem without accepting a format change. BZip3 is described as a spiritual successor, but the README does not document byte-for-byte compatibility with BZip2 archives or a transparent upgrade path for existing `.bz2` data. Users who need a drop-in replacement should verify decoding support in every consumer before migrating. The repository's disclaimer is unusually direct. It says not to compress data unless the user accepts the possibility, however small, that it will not be recoverable. For backups, release artifacts, and archival records, that warning makes a separate restore test mandatory. A tool can produce a small archive and still be inappropriate if the surrounding process cannot retain an untouched copy until successful decompression has been confirmed. ## License, maintenance, and upgrade work BZip3 is licensed under LGPL-3.0. The README clarifies that the project as a whole is not dual-licensed under LGPLv3 and Apache 2.0. It lists Apache 2.0 components for the runtime Burrows-Wheeler transform library `libsais` and LZP code, while other build-time and utility files carry separate notices, including GPL-3+ with an Autoconf exception, FSFAP, GPLv3, and BSD-2-clause. That breakdown is relevant to distributors and integrators because the runtime license is not the only license present in the repository. The repository is not archived. Its last push was on 2026-10-14, and the listed releases include 1.5.4 on 2026-09-07, 1.5.3 on 2025-08-13, and 1.5.2 on 2025-04-28. The README does not document a compatibility policy between those releases, so upgrading should include a test that reads files created by the previous version and a check that files written by the new version can be restored with the intended reader. The Autotools build and C API also create an integration cost. `bzip3.pc.in` and `bzip3-config.cmake.in` indicate packaging files for consumers, while `PORTING.md` is part of the repository layout. The README does not describe a stable API versioning policy, so projects embedding BZip3 should pin a release and review the relevant source and man-page changes before changing versions. ## Conclusion BZip3 suits users who prioritize compression ratio for text or code and can accommodate its memory requirements and recovery warning. It is a less natural choice for small files, constrained systems, or workflows that require a compact, widely supported compressor. Before adopting it, verify the build and command-line workflow on the target architecture, confirm that the required disk and memory capacity is acceptable, and test decompression against the specific data that will be stored. ## FAQ ### What is BZip3 used for? The README says BZip3 is a spiritual successor to BZip2 and excels at compressing text or code. Its published benchmark focuses on a large collection of Perl source archives. ### How do I install BZip3? For a source checkout, the README lists `./bootstrap.sh`, `./configure`, `make`, and `sudo make install`. On macOS, it gives `brew install bzip3`. ### Does BZip3 use less memory than BZip2? The README benchmark does not support that conclusion. It reports 18,301M for one high-thread BZip3 invocation and 12,178M for `bzip3 -e -b 511 -j 4 all.tar`, while the BZip2 line reports 8M. The figures come from different command settings, so they are not a controlled general comparison. ### Is BZip3 compatible with BZip2 files? The README calls BZip3 a spiritual successor to BZip2 but does not document drop-in compatibility with BZip2 archives. Existing `.bz2` workflows should be tested before migration. ### What license does BZip3 use? The README identifies LGPLv3 as the license for BZip3 as a whole and explicitly says it is not dual-licensed under LGPLv3 and Apache 2.0. Individual bundled components have separate notices. ## Sources - [iczelia/bzip3 on GitHub](https://github.com/iczelia/bzip3) - [Issues](https://github.com/iczelia/bzip3/issues) - [License: LGPL-3.0](https://github.com/iczelia/bzip3/blob/master/LICENSE) - [README](https://github.com/iczelia/bzip3/blob/master/README.md) - [Releases](https://github.com/iczelia/bzip3/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/iczelia-bzip3