HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
madler
zlib
C2017–2026
madler / zlib

zlib

A massively spiffy yet delicately unobtrusive compression library.

Data & DatabasesLibraries & SDKs
Explore on GitHubRead Hacker News discussions
27Distinct people
30Mentions
0Explicit recommenders
7.2KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A massively spiffy yet delicately unobtrusive compression library.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:03:16 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year30 dated mentions

Observed mentions: 2017-02-11 00:27:10 UTC to 2026-07-16 21:05:07 UTC.

0510152017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20172018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 13 mentions; 1 submissions, 12 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 5 mentions; 1 submissions, 4 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC101
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC000
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC000
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC202
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC202
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC13112
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC514
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC000
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC202
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC505

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
ZLIB DATA COMPRESSION LIBRARY zlib 1.3.2.1 is a general purpose data compression library. All the code is thread safe (though see the FAQ for caveats). The data format used by the zlib library is described by RFCs (Request for Comments) 1950 to 1952 at https://datatracker.ietf.org/doc/html/rfc1950 (zlib format), rfc1951 (deflate format) and rfc1952 (gzip format). All functions of the compression library are documented in the file zlib.h (volunteer to write man pages welcome, contact zlib@gzip.org). A usage example of the library is given in the file test/example.c which also tests that the library is working correctly. Another example is given in the file test/minigzip.c. The compression library itself is composed of all source files in the root directory. To compile all files and run the test program, follow the instructions given at the top of Makefile.in. In short "./configure; make test", and if that goes well, "make install" should work for most flavors of Unix. For Windows, use one of the special makefiles in win32/ or contrib/vstudio/ . For VMS, use make_vms.com. Questions about zlib should be sent to <zlib@gzip.org>, or to Gilles Vollant <info@winimage.com> for the Windows DLL version. The zlib home page is https://zlib.net/ . Before reporting a problem, please check this site to verify that you have the latest version of zlib; otherwise get the latest version and check whether the problem still exists or not. PLEASE read the zlib FAQ https://zlib.net/zlib_faq.html before asking for help. Mark Nelson <markn@ieee.org> wrote an article about zlib for the Jan. 1997 issue of Dr. Dobb's Journal; a copy of the article is available at https://zlib.net/nelson/ . The changes made in version 1.3.2.1 are documented in the file ChangeLog. Unsupported third party contributions are provided in directory contrib/ . zlib is available in Java using the java.util.zip package. Follow the API Documentation link at: https://docs.oracle.com/search/?q=java.util.zip . A Perl interface to zlib and bzip2 written by Paul Marquess <pmqs@cpan.org> can be found at https://github.com/pmqs/IO-Compress . A Python interface to zlib written by A.M. Kuchling <amk@amk.ca> is available in Python 1.5 and later versions, see https://docs.python.org/3/library/zlib.html . zlib is built into tcl: https://wiki.tcl-lang.org/page/zlib . An experimental package to read and write files in .zip format, written on top of zlib by Gilles Vollant <info@winimage.com>, is available in the contrib/minizip directory of zlib. Notes for some targets: - For Windows DLL versions, please see win32/DLL_FAQ.txt - For 64-bit Irix, deflate.c must be compiled without any optimization. With -O, one libpng test fails. The test works in 32 bit mode (with the -n32 compiler flag). The compiler bug has been reported to SGI. - zlib doesn't work with gcc 2.6.3 on a DEC 3000/300LX under OSF/1 2.1 it works when compiled with cc. - On Digital Unix 4.0D (formerly OSF/1) on AlphaServer, the cc option -std1 is necessary to get gzprintf working correctly. This is done by configure. - zlib doesn't work on HP-UX 9.05 with some versions of /bin/cc. It works with other compilers. Use "make test" to check your compiler. - For PalmOs, see https://palmzlib.sourceforge.net/ Acknowledgments: The deflate format used by zlib was defined by Phil Katz. The deflate and zlib specifications were written by L. Peter Deutsch. Thanks to all the people who reported problems and suggested various improvements in zlib; they are too numerous to cite here. Copyright notice: (C) 1995-2026 Jean-loup Gailly and Mark Adler This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software. Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions: 1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required. 2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software. 3. This notice may not be removed or altered from any source distribution. Jean-loup Gailly Mark Adler jloup@gzip.org madler@alumni.caltech.edu If you use the zlib library in a product, we would appreciate *not* receiving lengthy legal documents to sign. The sources are provided for free but without warranty of any kind. The library has been entirely written by Jean-loup Gailly and Mark Adler; it does not include third-party code. We make all contributions to and distributions of this project solely in our personal capacity, and are not conveying any rights to any intellectual property of any third parties. If you redistribute modified sources, we would appreciate that you include in the file ChangeLog history information documenting your changes. Please read the FAQ for more information on the distribution of modified source versions.
Read the full README on GitHub

What Hacker News says

30 sources
wahern·Jul 16, 2026
I built a benchmark harness for exploring compression of Lua script source files embedded in a Lua app binary as individual static constant C arrays. I settled on gzip, specifically deflate/inflate. Deflate does as well or better for small source files compared to xz, bzip2, and zstd.[0] More importantly, the inflate algorithm is tiny[1]; embedding the zstd decompressor blew up the binary. I also explored building precomputed dictionaries, which means you can easily embed the files individually (C source file inclusion and runtime loading through the Lua C API remains relatively straight-forward compared to gymnastics of parsing and transforming preprocessed files) while getting similar compression ratios as when compressing an enormous file (e.g. a concatenation of all the source files). This is trivial with the zstd reference utility. I
Read the rest
t's also simple for deflate, though you have to roll your own dictionary builder by hacking the zlib implementation, or just writing it from scratch[2]. But I never bothered implementing it beyond the benchmark harness. I probably would have stuck with deflate rather than switching to zstd just because the compiled inflate implementation is so small. [0] This is because the greatest advantage of the alternatives over deflate is the larger dictionary size they build up; deflate has a very small, upper bound. But for short inputs this advantage is diminished. [1] https://github.com/madler/zlib/blob/develop/contrib/puff/puf... [2] https://blog.cloudflare.com/improving-compression-with-prese...
In Optimizing Lua string literals to save 400 bytes
Rexxar·Mar 28, 2026
Original zlib code: https://github.com/madler/zlib/blob/develop/contrib/puff/puf... The code of the article: https://github.com/ieviev/mini-gzip/blob/main/src/main.rs Top level declarations of the C code: #define MAXBITS 15 #define MAXLCODES 286 #define MAXDCODES 30 #define MAXCODES #define FIXLCODES 288 struct state local int bits(struct state *s, int need) local int stored(struct state *s) struct huffman local int decode(...) local int construct(...) local int codes(...) local int fixed(...) local int dynamic(...) int puff(...) Top level declarations of the Rust code: const MAXBITS: usize = 15; const MAXLCODES: usize = 286; const MAXDCODES: usize = 30; const FIXLCODES: usize = 288; const MAXDIST: usize = 32768; struct State<'a> struct Huff
Read the rest
man<'a> fn decode fn construct fn codes fn fixed fn dynamic fn stored pub fn inflate
In Gzip decompression in 250 lines of Rust
nayuki·Mar 27, 2026
True. A most basic CRC implementation is about 7 lines of code: (presented in Java to avoid some C/C++ footguns) int crc32(byte[] data) { int crc = ~0; for (byte b : data) { crc ^= b & 0xFF; for (int i = 0; i < 8; i++) crc = (crc >>> 1) ^ ((crc & 1) * 0xEDB88320); } return ~crc; } Or smooshed down slightly (with caveats): int crc32(byte[] data) { int crc = ~0; for (int i = 0; i < data.length * 8; i++) { crc ^= (data[i / 8] >> (i % 8)) & 1; crc = (crc >>> 1) ^ ((crc & 1) * 0xEDB88320); } return ~crc; } But one reason that many CRC implementations are large is because they include a pre-computed table of 256× 32-bit constants so that one byte can processed at a time. For example: https://github.co
Read the rest
m/madler/zlib/blob/7cdaaa09095e9266dee21314...
In Gzip decompression in 250 lines of Rust
arp242·Dec 23, 2023
Most if not all of bash. zlib changed it just a few months ago (1.3 release from August): https://github.com/madler/zlib/issues/633 I've also seen it in some FreeBSD code, but that was quite a few years ago and I don't know to what degree that's been cleaned up – not so easy to grep for, but a quick check in git log shows e.g. https://github.com/freebsd/freebsd-src/commit/e5d0d1c5fbbc and some other things, so it seems there's still some K&R around. Probably others as well, this is what I happen to know from the top of my head.
In Xmas.c (1988)
nigeltao·Sep 22, 2023
Wuffs author here. It's not full-blown formal verification but it doesn't have to be. Unlike most formal verification projects that I've seen, the proof part of Wuffs isn't about correctness (proving that "this implementation satisfies the PNG specification"), it's about safety (proving that "this implementation won't read/write out of bounds"), which is much more tractable. Especially as the PNG spec (or WebP spec) doesn't mandate how to treat malicious input (like unbalanced Huffman tables). Wuffs doesn't have a WebP decoder yet but it's literally in the Roadmap and I've previously written the golang.org/x/image/webp package in the Go programming language. Wuffs does have a PNG decoder, PNG uses Deflate compression and Deflate and WebP's "decode a Huffman tree" data tables are very similar. Wuffs also has an equivalent of zlib's enough.
Read the rest
c program mentioned in the original blog post to calculate worst-case memory requirements. Wuffs' version is called script/print-deflate-huff-table-size.go and it says that, for a 9-bit primary table, we need 852 table entries. Round that up to 1024, for nearest power-of-two. If you look for HUFFS_TABLE_SIZE = 1024 and HUFFS_TABLE_MASK = 1023 in Wuffs' std/deflate source code, you'll notice that Wuffs' Deflate decoder isn't susceptible to the same problem as the C/C++ WebP decoder the original blog post discussed. This is because, unless the Wuffs compiler can prove otherwise, the code doesn't just look up the table like `this.huffs[0][i]`, it's like `this.huffs[0][i&mask]` and `i&mask` is always in bounds. The mask is either HUFFS_TABLE_MASK or it's of a refinement type guaranteed <= 511. The array is always (statically) allocated with 1024 entries even though enough.c says that, with dynamic allocation, we could possibly get away with a smaller table. As you already know, for Wuffs (and unlike C/C++), taking out the `&mask` will lead to a compile-time error. Wuffs code won't compile unless the compiler can prove that array indexes are always within bounds. From the grandparent: > this WebP bug occurred because the largest table size was formally proven but it didn't match what was fed to the source code With WebP+enough.c this 'largest table size' was calculated by exhaustive, brute-force search (not really a formal proof) but it was based on assumptions (balanced codes) that didn't match actual (malicious) input. Or, in zlib-the-library, there's other C code (https://github.com/madler/zlib/blob/ac8f12c97d1afd9bafa9c710...) that rejects unbalanced Huffman codes, but IIUC similar enforcement was (until very recently) missing in libwebp. With Wuffs, even if the worst-case calculation was based on an incorrect model (or forgetting to separately reject unbalanced codes), the end result (on malicious input) might be "the wrong pixels" but it shouldn't be "buffer overflow".
In The WebP 0day
lifthrasiir·Sep 12, 2023
After some more reading, I concluded that authors did think about this possibility but wrote a wrong code. I have mentioned that there was the hard-coded maximum number of entries. This is derived from zlib's enough.c [1], which determines the maximum possible size of 2-level table for given number of symbols, N and the maximum allowed bit length (here 15). I've verified that those numbers indeed come from this program: for ((color_cache_size = 0; color_cache_size < 12; ++color_cache_size)); do # Note that color_cache_size = 0 entirely disables the color cache, so no symbols ./enough $((256 + 24 + (($color_cache_size > 0) << $color_cache_size))) 8 15 done So at the worst case, there are 256 + 24 + 2^11 = 2328 symbols possible, and the maximum table size is 2704. (Caveat: I couldn't verify values for color_cache_si
Read the rest
ze >= 8 with the current version of enough.c. Probably the value was calculated with an alternative implementation using bigints.) So this bug cannot be found if any randomly constructed Huffman tree was thrown! But enough.c states that it covers "all possible valid and complete prefix codes". In the other words it assumes that the Huffman tree has been already verified to be correct. If it's not the case, it is very easy to make much worse cases. For example `enough.c 280 8 15` returns 654, which is possible with the following tree: Len Code range # Root entry Overhead # --- ------------------------------------ --- ----------------- -------- --- 1 0 1 0xxxxxxx 0 128 9 10000000:0 .. 11110110:1 238 10000000-11110110 2^1 119 11110111:0 1 11110111 2^2 1 10 11110111:10 .. 11110111:11 2 11111000:00 .. 11111110:11 28 11111000-11111110 2^2 7 11111111:00 .. 11111111:10 3 11111111 2^7 1 11 11111111:110 1 12 11111111:1110 1 13 11111111:11110 1 15 11111111:1111100 .. 11111111:1111111 4 But the following partial tree should be able to reach 768 entries: Len Code range # Root entry Overhead # --- ------------------------------------ --- ----------------- -------- --- 9 00000000:0 1 00000000 2^7 1 10 00000000:10 1 11 00000000:110 1 12 00000000:1110 1 13 00000000:11110 1 14 00000000:111110 1 15 00000000:1111110 .. 00000000:1111111 2 00000001:0000000 .. 00000010:1111111 256 00000001-00000010 2^7 2 00000011:0000000 .. 00000011:0001111 1 00000011 2^7 1 So the real issue here is that the lack of tree validation before the tree construction, I believe. I'm surprised that this check was not yet implemented (I actually checked libwebp to make sure that I wasn't missing one). Given this blind spot, an automated test based on the domain knowledge is likely useless to catch this bug. [1] https://github.com/madler/zlib/blob/master/examples/enough.c
In Chrome: Heap buffer overflow in WebP
lifthrasiir·Sep 10, 2022
It is actually possible to estimate the compression level without actually compressing everything again, because different levels use different strategies which can be identified in some cases. zlib in particular has three strategies [1] and preflate [2] leverages this to store the deflate stream reconstruction data without much bits. [1] https://github.com/madler/zlib/blob/21767c6/deflate.c#L134-L... [2] https://github.com/deus-libri/preflate/blob/master/preflate_...
In Gzip and Brotli Compression Level Estimator

Showing the 15 most recent of 30 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.