#zlib #zlib-ng #bindings #low-level #programs #libz #system

sys libz-sys

Low-level bindings to the system libz library (also known as zlib)

44 stable releases

new 1.1.18 May 24, 2024
1.1.16 Mar 21, 2024
1.1.12 Jul 26, 2023
1.1.8 May 28, 2022
0.1.0 Nov 27, 2014

#15 in Compression

Download history 561942/week @ 2024-02-05 570185/week @ 2024-02-12 526271/week @ 2024-02-19 573918/week @ 2024-02-26 562543/week @ 2024-03-04 554754/week @ 2024-03-11 599977/week @ 2024-03-18 598526/week @ 2024-03-25 626929/week @ 2024-04-01 585266/week @ 2024-04-08 602933/week @ 2024-04-15 613388/week @ 2024-04-22 566616/week @ 2024-04-29 568195/week @ 2024-05-06 602111/week @ 2024-05-13 564589/week @ 2024-05-20

2,332,306 downloads per month
Used in 3,054 crates (88 directly)


16K SLoC

C 15K SLoC // 0.2% comments Rust 1K SLoC // 0.0% comments


A common library for linking libz to Rust programs (also known as zlib).


This also serves as the source for the libz-ng-sys crate, which builds zlib-ng natively (not in zlib-compat mode). See README-zng.md for details.

High-level API

This crate provides bindings to the raw low-level C API. For a higher-level safe API to work with DEFLATE, zlib, or gzip streams, see flate2. flate2 also supports alternative implementations, including slower but pure Rust implementations.


This crate supports building either the high-performance zlib-ng (in zlib-compat mode), or the widely available stock zlib.

By default, libz-sys uses stock zlib, primarily because doing so allows the use of a shared system zlib library if available.

Any application or library designed for zlib should work with zlib-ng in zlib-compat mode, as long as it doesn't make assumptions about the exact size or output of the deflated data (e.g. "compressing this data produces exactly this many bytes"), and as long as you don't also dynamically pull in a copy of stock zlib (which will produce conflicting symbols). Nonetheless, for maximum compatibility, every library crate in a build must opt into allowing zlib-ng; if any library crate in your dependency graph wants stock zlib, libz-sys will use stock zlib.

Library crates depending on libz-sys should use:

libz-sys = { version = "1.1", default-features = false, features = ["libc"] }

(Omit the libc feature if you don't require the corresponding functions.)

This allows higher-level crates depending on your library to opt into zlib-ng if desired.

Building zlib-ng requires cmake unless the zlib-ng-no-cmake-experimental-community-maintained feature is enabled, in which case cc is used instead. Note that this option enables all compiler features that are supported for the given target, which may not compile on older compilers or targets without certain headers.

Crates that don't require compatibility with the zlib C API, and use zlib exclusively from Rust or support the zlib-ng native C API (prefixed with zng_) can use libz-ng-sys instead, which allows zlib and zlib-ng to coexist in the same program. See README-zng.md for details.

Minimum Supported Rust Version (MSRV) Policy

This crate uses the same MSRV policy as the flate2 crate: This crate supports the current and previous stable versions of Rust. Older versions of Rust may work, but we don't guarantee these will continue to work.


This project is licensed under either of

at your option.


Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in libz-sys by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.