libdeflate: a whole-buffer DEFLATE library for C, without streaming

Whole-buffer is the design, and it explains both the speed and the limit

libdeflate is a library for fast, whole-buffer DEFLATE-based compression and decompression. The README is unusually direct about the consequence of that word whole. You create a compressor or a decompressor, and you hand it a buffer. There is no streaming support, and the README explains why in two sentences: it has been considered, but it always significantly increases complexity and slows down fast paths, so it remains a future TODO. The guidance that follows is precise. If your application compresses data in chunks of less than about 1 MB, libdeflate is a great choice and that is what it is designed for, with transparent filesystem compression named as a good example. If your application compresses large files as a single compressed stream in the manner of the gzip program, then it is not for you. This is a library that says no to a whole category of use case rather than serving it badly.

Three formats, one DEFLATE core, and extra compression levels

The supported formats are DEFLATE in raw form, zlib which is DEFLATE with a zlib wrapper, and gzip which is DEFLATE with a gzip wrapper. The README states that libdeflate is significantly faster than the zlib library for both compression and decompression, especially on x86 and ARM processors, and that it provides optional high compression modes giving a better compression ratio than zlib's level 9. That last point is the one that distinguishes it from a pure speed play, because the usual trade-off in compression libraries is that the highest ratio is where speed falls off a cliff. Here the high modes are optional, so a caller picks the ratio it needs rather than accepting whatever the default gives. The README also includes a section comparing DEFLATE, zlib and gzip to make clear that the container differs while the compression algorithm does not.

The API is small and deliberately not zlib compatible

The README states plainly that the API is simple and not zlib-compatible. You create compressors and decompressors and use them on buffers, and libdeflate.h holds the details. What that means in practice is that a codebase already calling zlib cannot be switched over by changing a function name, and an existing zlib abstraction layer will not cover it without a new implementation behind the same interface. The upside of the divergence is the design freedom that the whole-buffer model allows. There is a related note for chunk-based compression: the uncompressed size of each chunk should generally be stored outside the compressed data, which lets you allocate the output buffer at the right size instead of guessing, although the decompression routines do optionally report the actual number of output bytes when you need it.

The build is CMake, but the sources are also drop-in

libdeflate uses CMake and builds the way any other CMake project does.

cmake -B build && cmake --build build

By default the build produces the static library, normally named libdeflate.a, the shared library, normally libdeflate.so, and the libdeflate-gzip program with its alias libdeflate-gunzip. libdeflate-specific options are set with the usual -DOPTION=VALUE form and are listed in CMakeLists.txt. Prebuilt Windows binaries are published on the releases page, which saves building on that platform entirely. The more interesting path is the one for projects that cannot take a CMake dependency. The library sources are kept compilable directly with no prerequisite configuration step, so you can add the source files to your application. You compile both lib/*.c and lib/*/*.c, and the architecture-specific code is handled inside the source files with #ifdef, so you do not have to exclude irrelevant paths yourself.

Compiler support is broad, and the gcc binutils pairing is a real trap

The supported compiler list is generous. gcc from v4.9, clang from v3.9 upstream or Xcode 8 on Apple, MSVC from Visual Studio 2019 version 16.8, and in general any C11-compatible compiler, with the caveat that a compiler pretending to be gcc, clang or MSVC has to be sufficiently compatible with the one it pretends to be. The README notes that these are minimums, and that a newer compiler allows more of the architecture-optimized code to be built, with the library most heavily optimized for gcc and clang although MSVC is supported fairly well. The binutils warning is the one worth memorising. A gcc paired with a much older binutils can produce instructions the assembler cannot assemble, and since v1.22 the CMake build detects an incompatible binutils and disables some optimized code accordingly. Outside CMake, the same mismatch shows up as assembler errors such as no such instruction.

Optimisation flags are less important than they look

The recommended optimisation flag is -O2, and the CMake build sets this for release builds. The README says -O3 is fine too, but that -O2 often actually gives better results, and that it is unnecessary to add flags such as -mavx2 or /arch:AVX2, though you can if you want to. The reason is runtime CPU feature detection: most of the relevant optimised functions are built regardless of such flags, and the appropriate ones are selected at runtime. That also explains a behaviour that would otherwise look like a bug, since -mno-avx2 does not cause all code using the corresponding instruction set extension to be left out of the binary. This is working-as-intended behaviour of the runtime dispatch, and it is what lets a single binary run well on both a machine with and without AVX2.

The bundled programs are conveniences, and the gzip one says so

Three command-line programs ship with the library. libdeflate-gzip can be a drop-in replacement for standard gzip under some circumstances, and the README is careful to qualify that: it needs a lot of memory to process large files and omits support for some infrequently-used options of GNU gzip, and it exists for convenience and is not meant to be the main use case of libdeflate. The benchmark program does round-trip compression and decompression of the input data and measures the speed, and it can use libdeflate, zlib, or a combination of the two. The checksum program checksums data with Adler-32 or CRC-32 and can optionally measure the speed. The last two are development tools that let you compare against zlib on your own data, which is the only way to know whether the optimisation flags matter for your workload.

MIT licensed, with C bindings maintained by other people

The library is MIT licensed, so it can be embedded in a proprietary product without source disclosure obligations. The README states that the project itself only provides a C library, and that anyone working in another language should use one of the listed community bindings, which include LibDeflate.NET for C#, libdeflate-pas for Delphi, go-libdeflate for Go, jlibdeflate for Java, and a Julia binding. That split has a practical consequence: a non-C caller inherits the pace and the API stability of a third-party binding rather than of the upstream project, and the bindings listed are separate repositories with their own maintainers. The release history shows v1.26 on 2026-08-22, v1.25 on 2025-11-01 and v1.24 on 2025-05-11, and the last push was on 2026-08-22, with a NEWS file holding the detailed release notes.

Editorial conclusion

libdeflate is worth adopting for a systems project that compresses many bounded buffers, since chunk-based compression is what the library was designed for and the architecture-specific code paths are selected at runtime rather than at compile time. It is the wrong choice for archiving tools and for any pipeline that expects a single continuous compressed stream, because the README states there is no streaming support and that it remains a future item. Verify first that your toolchain pairs gcc with a binutils version of comparable age, and that the calling convention matches what you need, since the Windows DLL exports cdecl while versions 1.4 through 1.12 used stdcall.

Frequently asked questions

Official sources

1. ebiggers/libdeflate on GitHub
2. Issues
3. License: MIT
4. README
5. Releases