A massively spiffy yet delicately unobtrusive compression library.

Related tags

Compression zlib

zlib 1.2.11 is a general purpose data compression library.  All the code is
thread safe.  The data format used by the zlib library is described by RFCs
(Request for Comments) 1950 to 1952 in the files
http://tools.ietf.org/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 [email protected]).  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

Questions about zlib should be sent to <[email protected]>, or to Gilles Vollant
<[email protected]> for the Windows DLL version.  The zlib home page is
http://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 http://zlib.net/zlib_faq.html before asking for help.

Mark Nelson <[email protected]> wrote an article about zlib for the Jan.  1997
issue of Dr.  Dobb's Journal; a copy of the article is available at
http://marknelson.us/1997/01/01/zlib-engine/ .

The changes made in version 1.2.11 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, documented at
http://java.sun.com/developer/technicalArticles/Programming/compression/ .

A Perl interface to zlib written by Paul Marquess <[email protected]> is available
at CPAN (Comprehensive Perl Archive Network) sites, including
http://search.cpan.org/~pmqs/IO-Compress-Zlib/ .

A Python interface to zlib written by A.M. Kuchling <am[email protected]> is
available in Python 1.5 and later versions, see
http://docs.python.org/library/zlib.html .

zlib is built into tcl: http://wiki.tcl.tk/4610 .

An experimental package to read and write files in .zip format, written on top
of zlib by Gilles Vollant <[email protected]>, 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 (formely 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.

- gzdopen is not supported on RISCOS or BEOS.

- For PalmOs, see http://palmzlib.sourceforge.net/


  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-2017 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
  [email protected]          [email protected]

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.

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.
  • Add continuous integration (CI)

    Add continuous integration (CI)

    To make it easier to accept contributions to zlib we should establish automated testing.

    This commit uses the existing test/example.c testing. It connects those tests to AppVeyor, allowing AppVeyor to mark commits as passing or failing the tests. It also automatically runs tests when a pull request is submitted or updated.

    There is some room for future expansion enabled, such as tracking the file and line of a failing test. This is thanks to @dankegel, who also got this working on CI providers other than AppVeyor.

    In order for this to land properly in madler/zlib, the README.md (the renamed and reformatted README file) must be updated with new [appveyor-shield] and [appveyor-link] links. These can be obtained by @madler once they enable AppVeyor on madler/zlib.

    opened by ProgramMax 58
  • zlib v1.2.12 fails to build shared library

    zlib v1.2.12 fails to build shared library

    When using configure, compiler is not correctly detected as gcc and -fPIC is not added to SFLAGS. This causes relocation issues when linking under Linux.

    opened by mtl1979 38
  • CVE-2018-25032 (zlib memory corruption on deflate)

    CVE-2018-25032 (zlib memory corruption on deflate)

    CVE-2018-25032 tracks a bug in zlib 1.2.11 which allows memory corruption when deflating (i.e., when compressing) if the input has many distant matches.

    There is a fix from @madler at https://github.com/madler/zlib/commit/5c44459c3b28a9bd3283aaceab7c615f8020c531

    @taviso reports at https://www.openwall.com/lists/oss-security/2022/03/24/1 that this patch never made it into a release, and at the time of writing no distros had picked it up as a fix.

    opened by vielmetti 29
  • Added GitHub Actions workflows

    Added GitHub Actions workflows


    • On each commit these workflows will be run to verify that project generation, source file compilation, and test cases run successfully.
    • On each pull request a workflow will be run to verify that all fuzzing tests pass successfully.

    Supports the following CI configurations:

    • CMake
      • Ubuntu GCC
      • Ubuntu GCC OSB (out of source build)
      • Ubuntu Clang
      • Ubuntu Clang Debug
      • Windows MSVC Win32
      • Windows MSVC Win64
      • macOS Clang
      • macOS GCC
    • Configure
      • Ubuntu GCC
      • Ubuntu GCC OSB (out of source build)
      • macOS GCC
    • Fuzz
      • OSS-Fuzz on pull request only

    Example runs can be found here: https://github.com/nmoinvaz/zlib/actions

    This PR does not change any source code and only adds yaml workflows. Take from this PR what you need.

    opened by nmoinvaz 28
  • Processing ZIP files in Java broken with latest zlib

    Processing ZIP files in Java broken with latest zlib

    After the upgrade to macOS High Sierra several Java applications that compress data stopped working correctly. Example are KNIME Analytics Platform or Tomcat. I was able to track down the problem to a potential bug in the zlib version shipped with High Sierra (1.12.11). Version 1.2.5 which is used in Sierra works find. The bug is caused by changing the compression levels for different entries. CreateZip.java.txt (rename to .java) demonstrates the problem. Compile and start with /tmp 100 as arguments. It works fine on any operating system except macOS High Sierra. If you comment the three lines that are marked with "Triggers the bug" the program also works as expected. This is a blocker for any Java application that changes compression levels on macOS therefore please consider this a critical bug.

    opened by sithmein 28
  • NEON implementation for Adler32

    NEON implementation for Adler32

    The checksum is calculated in the uncompressed PNG data and can be made much faster by using SIMD.

    Tests in ARMv8 yielded an improvement of about 3x (e.g. walltime was 350ms x 125ms for 4096x4096 bytes executed 30 times). That results in at least 18% improvement in PNG image decoding in Chromium.

    Further details at: https://bugs.chromium.org/p/chromium/issues/detail?id=688601

    opened by Adenilson 28
  • Please make new release

    Please make new release

    @madler: It is possible to release a new build with all build and CVE-2022-37434 fixes...? A or 1.2.13?

    It is really important to have a solution to current 1.2.12.


    • https://github.com/madler/zlib/pull/337
    • https://github.com/madler/zlib/issues/404
    • https://github.com/madler/zlib/issues/604
    • https://github.com/madler/zlib/pull/607
    • https://github.com/madler/zlib/issues/608
    • https://github.com/madler/zlib/issues/609
    • https://github.com/madler/zlib/issues/613
    • https://github.com/madler/zlib/pull/614
    • https://github.com/madler/zlib/issues/615
    • https://github.com/madler/zlib/issues/617
    • https://github.com/madler/zlib/issues/618
    • https://github.com/madler/zlib/issues/620 + https://github.com/Esri/zlib/commit/05b33dd27dbbfc9360d5c2430e228d7dc48f92f6
    • https://github.com/madler/zlib/issues/622
    • https://github.com/madler/zlib/issues/623
    • https://github.com/madler/zlib/pull/624
    • https://github.com/madler/zlib/issues/628
    • https://github.com/madler/zlib/issues/629
    • https://github.com/madler/zlib/issues/631
    • https://github.com/madler/zlib/pull/632
    • https://github.com/madler/zlib/issues/635
    • https://github.com/madler/zlib/pull/638
    • https://github.com/madler/zlib/pull/639
    • https://github.com/madler/zlib/pull/644
    • https://github.com/madler/zlib/pull/645
    • https://github.com/madler/zlib/issues/646
    • https://github.com/madler/zlib/issues/660
    • https://github.com/madler/zlib/issues/661
    • https://github.com/madler/zlib/pull/662
    • https://github.com/madler/zlib/issues/668
    • https://github.com/madler/zlib/issues/672
    • https://github.com/madler/zlib/pull/677

    In more:

    • https://github.com/madler/zlib/pull/557
    • https://github.com/madler/zlib/pull/657
    • https://github.com/madler/zlib/pull/681
    • https://github.com/madler/zlib/pull/691
    • https://github.com/madler/zlib/pull/694

    About GitHub:

    • https://github.com/madler/zlib/pull/492
    • https://github.com/madler/zlib/pull/506

    Thanks in advance.

    Linked to:

    • https://github.com/madler/zlib/issues/422

    cc: @gvollant.

    opened by Neustradamus 23
  • Zlib: deflateEnd() fails after deflateInit2()/deflateReset() when initialized for

    Zlib: deflateEnd() fails after deflateInit2()/deflateReset() when initialized for "Raw Deflate Compression"

    Description of the problem is:

    deflateInit () for raw deflate moves internal state to BUSY_STATE (where as it is INIT_STATE for zlib). BUSY_STATE is considered to be == INIT_STATE for raw deflate. So, when deflateEnd() is called, it has no way to identify whether stream is in the start or middle of core deflate operation() thus reports an Z_DATA_ERROR.

    How does it affect:

    //This will work: deflateInit2() deflate(strmp,Z_FINISH); deflateEnd()

    //This will not work deflateInit2() while(cnt—) { deflate(strmp,Z_FINISH); deflateReset()<--required to re-initiate deflate() on next input. } deflateEnd();

    test_def_init_term.c - a simple test case to reproduce issue.

    opened by 1234sv 20
  • gzseek broken on uncompressed streams on Windows

    gzseek broken on uncompressed streams on Windows

    On Windows, when calling gzopen on a plain text file, reading some bytes (at least 1), then calling gzseek(f, 0L, SEEK_SET), all subsequent gzread calls fail (they return 0).

    This does not happen when opening a compressed stream.

    In contrast, calling gzrewind(f) (which should be equivalent to the above, according to the documentation in "zlib.h") always works. Also, on Linux and MacOSX there is no such issue.

    I'm using zlib 1.2.8, and Windows 7 32bit (but I believe 64bit is also affected).

    Here is a simple test file which shows the problem (assuming "tst.tmp.txt" is any plain text file):

    #include <stdio.h>
    #include <zlib.h>
    int main(int argc,char *argv[])
        char buf[1000];
        int ret;
        gzFile f = gzopen("tst.tmp.txt", "rb");
        //gzFile f = gzopen("tst.tmp.gz", "rb"); // this works
        while (!gzeof(f)) {
            ret = gzread(f, buf, 1);
            if (!ret) {
                printf("READ FAILED\n");
            } else {
                printf("%c %i\n", buf[0], buf[0]);
        ret = gzseek(f, 0, SEEK_SET);
        printf("SEEK RETURNED: %i\n", ret);
        while (!gzeof(f)) {
            ret = gzread(f, buf, 1);
            if (!ret) {
                printf("READ FAILED\n");
            } else {
                printf("%c %i\n", buf[0], buf[0]);
        return 0;

    when running the code, the first while loop succeeds, then gzseek returns 0, and subsequent gzreads fail. If the first while loop is omitted, the rest succeeds, but as long as a single byte is read the bug is observed.

    opened by carlobaldassi 20
  • Better control/API over runtime logging from zlib?

    Better control/API over runtime logging from zlib?

    zlib has the ability to log runtime log messages. These log messages are only logged if a compile/build time flag is enabled ZLIB_DEBUG. This then means that it all depends on who/how the library is built for logging to be available at runtime.

    Recently, we have been trying to solve an issue in zlib that's shipped in macos aarch64 systems. The zlib shipped in that system wasn't built with ZLIB_DEBUG enabled (we verified it by calling zlibCompileFlags() at runtime and checking its output as noted in https://github.com/madler/zlib/blob/master/zlib.h#L1185). This effectively means that to be able to investigate the issue we need to rebuild that library with ZLIB_DEBUG, which isn't feasible given the lack of access to the actual source and the actual build command/configurations that were used to build it originally.

    Would it be feasible to introduce a way where this crucial logging can be enabled at runtime without having to rebuild the library? Perhaps an explicit API on the zlib library which enables the logging or maybe some runtime environment variable which enables it? I don't know if there's a precedent to allow environment variables to enable things like this, so if that's not a possibility then an API that the library's client is expected to call, should be fine perhaps?

    opened by jaikiran 18
  • Please fix 1.2.12 compile

    Please fix 1.2.12 compile

    Hi Mr. Adler,

    I can't build zlibwapi.dll from your new version 1.2.12 because of errors during the compiling process using Visual Studio v17 2022. The previous version 1.2.11 worked. I see many people have this problem. Can you please make a new release?

    Thank you so much.

    opened by Spatzendame 16
  • minizip: Convert old K&R function definition

    minizip: Convert old K&R function definition

    All the other functions in the same file were converted from K&R style to normal function argument declarations in d004b047838a7e803818b4973a2e39e0ff8c1fa2

    opened by jnohlgard 1
  • Remove unsetting _FILE_OFFSET_BITS

    Remove unsetting _FILE_OFFSET_BITS

    This does not work when enabling 64bit time_t with glibc which is enabled with -D_TIME_BITS=64, since it also needs _FILE_OFFSET_BITS=64 and this does not work when its undefined explicitly

    Signed-off-by: Khem Raj [email protected]

    opened by kraj 0
  • Fixed building with SAS/C for AmigaOS/68k

    Fixed building with SAS/C for AmigaOS/68k


    Please find my changes to fix the broken build for the good old Amiga below. It should not harm any other platform but just bring the Amiga relevant files up to date again. Besides that, I took the freedom to add a few lines of documentation to make zlib more accessible to other Amiga developers. I would really appreciate if my PR would be accepted.

    Thanks for your efforts,


    opened by christoph-fassbach 0
  • Add package export to installation

    Add package export to installation

    I'm trying build minizip with a locally built zlib because my circumstances don't allow for an internet connection while building minizip. Minizip will basically only look for zlib with find_package or fetch it, so I've had to add package export to my local copy of zlib. But I'm not sure there's a downside to having that all the time, so maybe you add it to the CMakeLists.txt? Replace:

        install(TARGETS zlib zlibstatic


        install(TARGETS zlib zlibstatic
        install(EXPORT ${PROJECT_NAME}
                DESTINATION "${INSTALL_LIB_DIR}/cmake/${PROJECT_NAME}"
                NAMESPACE "ZLIB::")

    Or something similar at any rate! Thanks!

    opened by AndrewAtAvenza 2
  • Add FetchContent compatibility

    Add FetchContent compatibility

    I prefer to use FetchContent for dependency management. With this:

        GIT_REPOSITORY "https://github.com/madler/zlib.git"

    the whole process of cloning the repo, generating and building it as a dependency might be automated by cmake.

    The problem is that the example executable relies on the assumption that the whole project with the headers is the top-level cmake project. And of course this is not true in case of FetchContent which will download zlib as a subdirectory.

    There are several different approaches on how to fix this. But the simplest one I can see is to add an option to disable tests and examples, like ZLIB_BUILD_TESTS.

    I can provide an example project that uses zlib as 3rdparty via FetchContent to reproduce the issue if needed.

    opened by hopeless-programmer-online 0
  • When Z_SOLO is defined on 64-bit Windows, z_size_t is defined incorrectly

    When Z_SOLO is defined on 64-bit Windows, z_size_t is defined incorrectly

    Documentation says z_size_t should be defined as smallest integer type that can hold a pointer, but unsigned long is 32 bits on 64-bit Windows and as such can't hold a pointer and will truncate. Only integer type that doesn't require any header file and can contain a pointer is unsigned __int64. This will also affect total_in and total_out in z_stream_s; compress, compress2, compressBound, uncompress and uncompress2 that use unsigned long to hold length.

    To detect 64-bit Windows, preprocessor macro _WIN64 can be used.

    opened by mtl1979 0
Mark Adler
Mostly harmless.
Mark Adler
LZFSE compression library and command line tool

LZFSE This is a reference C implementation of the LZFSE compressor introduced in the Compression library with OS X 10.11 and iOS 9. LZFSE is a Lempel-

null 1.7k Jan 4, 2023
Small strings compression library

SMAZ - compression for very small strings ----------------------------------------- Smaz is a simple compression library suitable for compressing ver

Salvatore Sanfilippo 1k Dec 28, 2022
A simple C library implementing the compression algorithm for isosceles triangles.

orvaenting Summary A simple C library implementing the compression algorithm for isosceles triangles. License This project's license is GPL 2 (as of J

Kevin Matthes 0 Apr 1, 2022
Advanced DXTc texture compression and transcoding library

crunch/crnlib v1.04 - Advanced DXTn texture compression library Public Domain - Please see license.txt. Portions of this software make use of public d

null 775 Dec 26, 2022
Brotli compression format

SECURITY NOTE Please consider updating brotli to version 1.0.9 (latest). Version 1.0.9 contains a fix to "integer overflow" problem. This happens when

Google 11.7k Dec 29, 2022
Extremely Fast Compression algorithm

LZ4 - Extremely fast compression LZ4 is lossless compression algorithm, providing compression speed > 500 MB/s per core, scalable with multi-cores CPU

lz4 7.9k Dec 31, 2022
Zstandard - Fast real-time compression algorithm

Zstandard, or zstd as short version, is a fast lossless compression algorithm, targeting real-time compression scenarios at zlib-level and better comp

Facebook 19.2k Jan 1, 2023
Lossless data compression codec with LZMA-like ratios but 1.5x-8x faster decompression speed, C/C++

LZHAM - Lossless Data Compression Codec Public Domain (see LICENSE) LZHAM is a lossless data compression codec written in C/C++ (specifically C++03),

Rich Geldreich 641 Dec 22, 2022
A bespoke sample compression codec for 64k intros

pulsejet A bespoke sample compression codec for 64K intros codec pulsejet lifts a lot of ideas from Opus, and more specifically, its CELT layer, which

logicoma 34 Jul 25, 2022
A variation CredBandit that uses compression to reduce the size of the data that must be trasnmitted.

compressedCredBandit compressedCredBandit is a modified version of anthemtotheego's proof of concept Beacon Object File (BOF). This version does all t

Conor Richard 18 Sep 22, 2022
Data compression utility for minimalist demoscene programs.

bzpack Bzpack is a data compression utility which targets retrocomputing and demoscene enthusiasts. Given the artificially imposed size limits on prog

Milos Bazelides 20 Jul 27, 2022
gzip (GNU zip) is a compression utility designed to be a replacement for 'compress'

gzip (GNU zip) is a compression utility designed to be a replacement for 'compress'

ACM at UCLA 8 Nov 6, 2022
Better lossless compression than PNG with a simpler algorithm

Zpng Small experimental lossless photographic image compression library with a C API and command-line interface. It's much faster than PNG and compres

Chris Taylor 214 Dec 23, 2022
A C++ static library offering a clean and simple interface to the 7-zip DLLs.

bit7z A C++ static library offering a clean and simple interface to the 7-zip DLLs Supported Features • Getting Started • Download • Requirements • Bu

Riccardo 326 Jan 1, 2023
miniz: Single C source file zlib-replacement library, originally from code.google.com/p/miniz

Miniz Miniz is a lossless, high performance data compression library in a single source file that implements the zlib (RFC 1950) and Deflate (RFC 1951

Rich Geldreich 1.6k Jan 5, 2023
Fork of the popular zip manipulation library found in the zlib distribution.

minizip-ng 3.0.0 minizip-ng is a zip manipulation library written in C that is supported on Windows, macOS, and Linux. Developed and maintained by Nat

zlib-ng 971 Jan 4, 2023
Fork of the popular zip manipulation library found in the zlib distribution.

minizip-ng 3.0.1 minizip-ng is a zip manipulation library written in C that is supported on Windows, macOS, and Linux. Developed and maintained by Nat

zlib-ng 971 Jan 4, 2023
PhysFS++ is a C++ wrapper for the PhysicsFS library.

PhysFS++ PhysFS++ is a C++ wrapper for the excellent PhysicsFS library by Ryan C. Gordon and others. It is licensed under the zlib license - same as P

Kevin Howell 80 Oct 25, 2022
An embedded-friendly library for decompressing files from zip archives

An 'embedded-friendly' (aka Arduino) library to extract and decompress files from ZIP archives

Larry Bank 33 Dec 30, 2022