bit7z: a C++ wrapper around the 7-Zip shared libraries

A small interface over 7-Zip's own libraries

bit7z is described in the repository as a C++ static library offering a clean and simple interface to the 7-zip shared libraries, and in the README as a cross-platform C++ static library that allows the compression and extraction of archive files through a clean and simple wrapper interface to the dynamic libraries from 7-Zip.

That is the entire architectural idea, and it is a good one to have a clear position on. The 7-Zip codebase is a large, capable piece of software with an API that is not designed to be pleasant to call from application code. bit7z does not reimplement any of it. It links against the 7-Zip shared libraries and puts a narrower, more C++-shaped interface on top, so that the application code deals with a handful of wrapper types instead of the full 7-Zip surface.

Two consequences follow directly from the words static and dynamic in that sentence, and they pull in opposite directions. In your favour, the interface is small and the library compiles into your binary, so there is no wrapper to deploy alongside it. Against you, the 7-Zip shared libraries are still a runtime dependency of your product, so you have to ship them and match their version to the wrapper.

The licence is MPL-2.0, the primary language is C++, the default branch is master, and the homepage is the project site at rikyoz.github.io/bit7z. The last push was on 2026-10-14, and the recent releases are v4.0.12 in May 2026, v4.1.0-beta in the same month and v4.1.0 in June 2026.

The formats, read from the project's own labels

The README excerpt available here is largely navigation, so the most reliable description of the feature set comes from the repository's own topic labels, which are chosen by the author and therefore a fair summary of what the project is about.

The format topics are 7-zip, 7z, zip, tar, gzip, bzip2 and rar, with archives and extraction and compression alongside them. So the library covers the common compression formats rather than only the native one, which is the practical point: an application that has to open a zip that a user sent it and write a 7z that a user asked for needs a wrapper over all of them, and that is the case bit7z is built for.

The feature topics are more revealing about the design goals: archives-metadata, encrypted-archives, multi-volume-archives and in-memory. The first says the library exposes information about the contents of an archive rather than only being able to unpack it. The second says encrypted archives are in scope, which for an archive library is a security-relevant feature and not a small one. The third says multi-volume archives, the split archives that 7-Zip produces as a set of numbered volumes, are handled. The fourth says in-memory, which is the capability that distinguishes a wrapper around a file-oriented library from one that can also work on buffers, which is what you want when the archive is arriving over a network or is already decompressed in memory.

The README's own navigation lists a Supported Features section, which is where the definitive list lives, and the Getting Started section carries the basic source code examples.

A wide platform and compiler matrix, and one badge that disagrees with itself

The badge row in the README is the most information-dense part of the document, and it pins down what the library is expected to build on.

The platforms are Windows, Linux, macOS and BSD, and the architectures are x86, x64, arm and arm64. The compilers are MSVC 2015 or later on Windows, MinGW 6.4 or later, GCC 4.9 or later, and Clang 3.6 or later on Unix. The language standard badge says C++14, which is a notably old floor and is what allows the library to be consumed by projects that cannot move to a newer standard yet.

There is a small inconsistency in that row worth mentioning, because it is the kind of thing that sends someone looking for a compiler version that does not exist. The Clang badge image is labelled 3.6 or later while its own tooltip text says Clang 3.5 or later. One of the two is out of date, and the safe assumption is the higher number.

The breadth of that matrix is also a statement about the underlying dependency. 7-Zip itself is portable to a remarkable set of systems, and bit7z inherits that, which is why a Windows-only archive wrapper would be a different kind of project. The BSD entry alongside the other three is a hint that the library is used in more conservative environments than a typical desktop application would suggest.

For a build in CI, the practical consequence is that the minimum compiler versions are the ones to write into your build matrix, and the arm and arm64 entries mean the library is expected to run on the hardware that runs embedded Linux.

The README is written as a manual with eight sections

The navigation bar at the top of the README lists the sections, and the titles are given in the anchors themselves: Supported Features, Getting Started, Download, Requirements, Installation, Configuration, Support the Project and License.

That order is a build order. Supported Features comes first because it is the compatibility contract. Getting Started carries the basic source code examples, with the anchor title describing them as such. Download is for pre-compiled packages, which is worth noting for a C++ library, since shipping a build of a static library to consumers is an unusual courtesy and implies the project supports platforms where building it locally is a chore. Requirements states what the consumer needs to have. Installation and Configuration then cover getting it into a project and switching its options on. The last two sections are the funding request and the licence.

The presence of a Download section alongside a Configuration section is the interesting pair, because configuration implies there is something to configure, and a wrapper around a fixed 7-Zip installation would not need a configuration section at all.

The repository structure matches a library rather than an application. There is include/ for the public headers and src/ for the implementation, which is the layout a consumer's include path points at, a tests/ directory for the test suite, a cmake/ directory beside the top-level CMakeLists.txt for the module files, a docs/ directory for the documentation that the README site is built from, an appveyor.yml for Windows continuous integration, and a CODE_OF_CONDUCT.md alongside the LICENSE file.

A static library over dynamic libraries, and what to check about that

The combination of static and dynamic in the project's own description is the part worth thinking through before you adopt it.

bit7z compiles into your binary as a static library, and it calls into the 7-Zip shared libraries at run time. So your product ends up carrying two things: the wrapper, statically linked, and the 7-Zip runtime, dynamically. The wrapper is the part that is small and stable and covered by MPL-2.0. The runtime is a third-party binary you have to obtain, ship and keep in step with the wrapper's expectations.

That is a real difference from an archive library written from scratch, and it is the price of the clean interface. In exchange you get the whole of 7-Zip's format coverage, including the parts that would take years to reimplement, and you get it behind an interface that does not require you to learn the 7-Zip API.

The licence question follows from the same arrangement. MPL-2.0 is a file-level copyleft licence: if you modify the files covered by it, those modifications have to be made available under the same licence, and it is a weak copyleft in the sense that it attaches to the files rather than to the whole of your product. For a static library, which is a substantial part of your binary, the practical questions are about which files you modified and how you distribute the result. That is a question for whoever handles licence compliance in your organisation rather than for a README, and the LICENSE file in the repository is the document to give them.

A fast 4.x line, and a repository still being worked on

The release history is short and recent, and it says the project is active.

Version 4.0.12 was published on 2026-05-15, a 4.1.0 beta on 2026-05-18, and 4.1.0 on 2026-06-17. A patch, a beta and a minor in the same quarter, with the beta three days after the patch, is the pattern of a project that is stabilising a new minor version rather than one that ships on a schedule.

The last push was on 2026-10-14, four months after the last release, and the repository is not archived. So the tree contains work that has not been tagged, which is the ordinary state of a library between releases and the reason to check the release notes before pinning a version rather than assuming the newest tag contains everything.

What to verify, then, before you build on it. Read Supported Features against the archive types and the operations your application actually performs, because a wrapper's value depends on the corner you care about, encrypted archives, multi-volume sets, in-memory buffers, and the metadata. Read Requirements for the 7-Zip version your wrapper expects. And read the Getting Started examples, which are the fastest way to judge whether the interface is as clean as the README claims, since the claim is about the interface and the examples are the interface.

Editorial conclusion

Adopt bit7z if you need archive handling in a C++ application and would rather not embed 7-Zip's own API, because the whole point of the project is to hide that interface behind a small one, and the platform and compiler matrix is wide enough for it to build on the systems you already support. Do not adopt it if you cannot ship the 7-Zip runtime with your product, since bit7z is a static wrapper over dynamic libraries rather than a self-contained implementation, and check the licence terms for how a modified copy is distributed. Before you commit, read the Supported Features and Requirements sections in the README rather than the introduction, because the feature list is what tells you whether your particular archive type and your particular platform are covered, and note that the 4.x releases stopped in June 2026 while the repository was still being worked on in October.

Frequently asked questions

Official sources

1. License: MPL-2.0
2. Project website
3. README
4. Releases
5. rikyoz/bit7z on GitHub