zlib-rs: a memory-safe zlib for Rust callers and for C programs that link zlib

Two crates from one implementation, for two very different callers

zlib-rs is described as a safer zlib, and the repository contains a Rust implementation of the zlib file format that is compatible with the zlib API.

That one implementation is published as two public crates. The first is zlib-rs, a Rust implementation based on zlib with a safe Rust API, and the readme is direct that this API is under development and still unstable. The second is libz-rs-sys, a zlib-compatible C API for use in non-Rust applications.

The two-crate split is the whole design. A Rust caller gets a safe API and no C in the dependency tree. A C caller gets the same implementation exposed through the zlib C API, as a shared object that a C program dynamically links to, and the readme points at the libz-rs-sys-cdylib example in the repository for how to build and use it.

That second path is the interesting one. Replacing the zlib a C program links against, in a build that produces the same compressed bytes, removes a large body of C from the attack surface without asking the C codebase to change. That is a different proposition from porting the program to Rust, and it is considerably cheaper.

The project is part of Trifecta Tech Foundation's data compression initiative, and the initial development was started and funded by the Internet Security Research Group as part of the Prossimo project.

Adopting it from Rust, and the flate2 feature gate that does the work

For Rust projects, the readme is admirably brief about the mechanics, because the integration is a feature flag rather than a rewrite.

By far the easiest way to use zlib-rs is through the flate2 crate, by simply enabling the zlib-rs feature gate, which enables the zlib-rs backend. That is the whole instruction.

This matters because flate2 is the abstraction most Rust code already uses for deflate, and flate2 supports several backends. A project that already calls flate2 can switch backends by changing a feature in Cargo.toml, with no change to the calling code. The risk profile of the change is therefore a dependency and an output-compatibility question, not a code-change question.

For C projects, the route is a shared object file built for usage by C programs that dynamically link to zlib, with the example in the libz-rs-sys-cdylib directory showing the shape of it. That directory is excluded from the Cargo workspace, which the workspace manifest states explicitly, so it is built separately from the crates.

The two public crates are versioned together at 0.6.8 in the workspace manifest, with the Rust minimum supported version set to 1.75 and edition 2021. The workspace also pulls in libz-sys with the zlib-ng feature, described in a comment as using libz-ng in libz compat mode, which is how the compatibility tests compare the two implementations.

Performance claims and the compiler flags that move them

The readme's performance statement is short: performance is generally on-par with zlib-ng.

That is a modest claim and the comparison target is telling. zlib-ng is the SIMD-accelerated fork of zlib that is the usual answer when plain zlib is too slow, so on-par with zlib-ng means the Rust implementation is being compared against the fast C option rather than the original.

Two compiler flags are documented as ways to improve performance, and the readme is careful about the caveats on each.

The first is target-cpu, and the example is:

RUSTFLAGS="-Ctarget-cpu=native" cargo build --release ...

Providing more information about the SIMD capabilities of the target machine can improve performance. The resulting binary statically assumes the SIMD capabilities of the current machine, and the readme warns in bold terms that binaries built this way almost certainly crash on systems that do not have the specified CPU, and that the flag should only be used if you control deployment and can guarantee the CPU assumptions are never violated. That is a distribution constraint, not a build flag, and for anything shipped to a fleet of machines it is the difference between a portable binary and a broken one.

The second flag targets small inputs, and the warning is much softer:

RUSTFLAGS="-Cllvm-args=-enable-dfa-jump-thread" cargo build --release ...

The readme puts it around 10% boost when the input arrives in chunks of 16 bytes, and a couple of percent for chunks under 1024 bytes, with the effect not significant beyond that. It can lead to longer compile times, but otherwise has no adverse effects.

The dev profile in the workspace manifest sets opt-level 1, with a comment saying it is required for the tail calls in inflate to optimize, which is a small piece of evidence about how the inflate implementation is written.

What is in the repository, and how it is checked

The top-level tree shows a project with real testing infrastructure rather than a single library crate.

There is a fuzz/ directory, which is the expected answer to the question of whether a reimplementation of a binary format parser is safe against hostile input. There is a test-libz-rs-sys/ crate, which is the C-facing test surface. There is libz-rs-sys-cdylib/ for the shared library build, and a docs/ directory. Two files at the root, ROADMAP.md and SECURITY.md, are the kind of thing a memory-safety project publishes and a general-purpose library rarely does.

The workspace manifest also shows how the compatibility testing works. The dev dependencies include libz-sys with the zlib-ng feature, commented as using libz-ng in libz compat mode, and arbitrary and quickcheck for property-based testing, which is the right tool for checking that a compressor and a decompressor agree on arbitrary inputs.

The repository also carries zlib_benchmarks.json and the silesia-small.tar and silesia-small.tar.gz files. The Silesia corpus is the standard reference set for compression benchmarks, and shipping a small slice of it in the repository means the benchmarks can be reproduced without downloading a hundred megabytes first.

The readme acknowledges the debt the project owes: it is heavily based on the zlib and zlib-ng projects, which is the correct attribution for a reimplementation of a widely deployed format and matters for the licence question below.

Licence, versioning and the honest limits of the claim

The licence recorded for the crates is Zlib, and the repository carries a LICENSE file. That is the permissive licence named after the library itself, and it is the licence a zlib-compatible implementation can ship under, which is a deliberate part of the design: the point of libz-rs-sys is that a C project can swap implementations without a licensing conversation.

The versioning is where the caution belongs. The workspace is at 0.6.8, with v0.6.8 released on 2026-09-15, v0.6.7 on 2026-08-03 and v0.6.6 on 2026-07-09, so the release cadence is roughly monthly on a pre-1.0 line. The readme says the Rust API is under development and still unstable, and the repository is not archived with the last push on 2026-10-08.

The third limit is functional coverage, and the readme does not enumerate it. The claim is compatibility with the zlib API and the zlib file format, and the interesting question for an adopter is how much of the API is covered, which functions are stubs, and whether the edge cases of the format, such as unusual window sizes or preset dictionary handling, are exercised. The test-libz-rs-sys crate and the fuzzing directory are where that evidence lives.

A team replacing zlib in production should read SECURITY.md, which is the file that explains the project's own threat model, before reading the performance numbers.

Editorial conclusion

zlib-rs fits a C project that links zlib today and wants the same API with a memory-safe implementation behind it, or a Rust project that wants deflate without pulling in a C dependency. It does not fit a project that needs a stable public API today, because the Rust side is stated to be under development and unstable, or a project that needs the full zlib feature set without checking what is implemented. Before adopting it, read the ROADMAP.md and SECURITY.md in the repository, check which zlib functions the libz-rs-sys C layer actually covers, and verify the compressed output against the reference zlib on your own data.

Frequently asked questions

Official sources

1. License: Zlib
2. Project website
3. README
4. Releases
5. trifectatechfoundation/zlib-rs on GitHub