# Deflate

> Mediated Wiki article. Canonical URL: https://mediated.wiki/source/Deflate
> Markdown URL: https://mediated.wiki/source/Deflate.md
> Source: https://en.wikipedia.org/wiki/Deflate
> Source revision: 1339410905
> License: Creative Commons Attribution-ShareAlike 4.0 International (https://creativecommons.org/licenses/by-sa/4.0/)

Lossless compression algorithm

This article is about the compression algorithm. For other uses, see [Deflation (disambiguation)](/source/Deflation_(disambiguation)).

This article may contain original research. Please improve it by verifying the claims made and adding inline citations. Statements consisting only of original research should be removed. (May 2025) (Learn how and when to remove this message)

Deflate Developed by Phil Katz, PKWare Initial release 21 August 1990; 35 years ago (1990-08-21) Compression LZ77, Huffman coding Standard RFC 1951 Open format? Yes Free format? Yes Website pkware.com

In [computing](/source/Computing), **Deflate** (stylized as **DEFLATE**, and also called **Flate**[1][2]) is a [lossless data compression](/source/Lossless_data_compression) algorithm[a] that uses a combination of [LZ77](/source/LZ77) and [Huffman coding](/source/Huffman_coding). It was designed by [Phil Katz](/source/Phil_Katz), for version 2 of his [PKZIP](/source/PKZIP) archiving tool. Deflate was later specified in [Request for Comments](/source/Request_for_Comments) (RFC) 1951 (1996).[4]

Katz also designed the original [algorithm](/source/Algorithm) used to construct Deflate streams. This algorithm received [software patent](/source/Software_patent) [U.S. patent 5,051,745](https://patents.google.com/patent/US5051745), assigned to [PKWare](/source/PKWare), Inc.[5][6] As stated in the RFC document, an algorithm producing Deflate files was widely thought to be implementable in a manner not covered by patents.[4] This led to its widespread use. For example, in the [zlib data format](/source/Zlib_data_format), [gzip file format](/source/Gzip_file_format), Portable Network Graphics ([PNG](/source/PNG)) image file, [ZIP](/source/ZIP_(file_format)) file format for which Katz originally designed it. The patent has since expired.

## Block structure

Deflate compression takes any sequence of [bytes](/source/Byte) and outputs a **sequence of blocks** (commonly called *Deflate stream*). Deflate decompression takes a sequence of blocks and outputs the original sequence of bytes.

[Endianness](/source/Endianness) is **little-endian**. **Bit 0** is the [least significant bit](/source/Least_significant_bit) in a byte.[7]

Each block has a 3-bit [header](/source/Header_(computing)) with two fields:[8]

- **BFINAL** (first bit): 1 if this is the **last block** in the sequence, else 0.

- **BTYPE** (next two bits): Block type - 00: **No compression** (sometimes called *stored*). Any bits up to the next byte boundary are ignored. The rest of the block consists of 16-bit **LEN**, 16-bit **NLEN** ([one's complement](/source/One's_complement) of LEN), and LEN bytes of **uncompressed data**, i.e. up to 65,535 (216 − 1) bytes. Useful for incompressible data (e.g. high-entropy, random, or already compressed), adding minimal overhead (i.e. ~5 bytes per block). - 01: A **static Huffman** compressed block, using a pre-agreed [Huffman tree](/source/Huffman_coding) defined in the RFC. - 10: A **dynamic Huffman** compressed block, complete with the Huffman table supplied. - 11: **Reserved** (error).

Most compressible data will end up being encoded using method 10, the *dynamic Huffman* encoding, which produces an optimized Huffman tree customized for each block of data individually. Instructions to generate the necessary Huffman tree immediately follow the block header. The static Huffman option is used for short messages, where the fixed saving gained by omitting the tree outweighs the percentage compression loss due to using a non-optimal (thus, not technically Huffman) code.

Compression is achieved through two steps:

- Matching and replacing duplicate strings with pointers

- Replacing symbols with new, weighted symbols based on use frequency

### Duplicate string elimination

Further information: [LZ77 and LZ78](/source/LZ77_and_LZ78) and [LZSS](/source/LZSS)

Within compressed blocks, if a duplicate series of bytes is spotted (a repeated string), then a back-[reference](/source/Reference_(computer_science)) is inserted, linking to the prior location of that identical string instead. An encoded match to an earlier string consists of an [8-bit](/source/8-bit_computing) length (3–258 bytes) and a 15-bit distance (1–32,768 bytes) to the start of the duplicate. Relative back-references can be made across any number of blocks, as long as the distance appears within the last 32 [KiB](/source/Kibibyte) of uncompressed data decoded (termed the *sliding window*).

If the distance is less than the length, the duplicate overlaps itself, indicating repetition. For example, a run of 10 identical bytes can be encoded as one byte, followed by a duplicate of length 9, starting with the prior byte.

Searching the preceding text for duplicate substrings is the most computationally expensive part of the Deflate algorithm, and the operation which compression level settings affect.

### Bit reduction

Further information: [Huffman coding](/source/Huffman_coding)

The second compression stage consists of replacing commonly used symbols with shorter representations and less commonly used symbols with longer representations. The method used is [Huffman coding](/source/Huffman_coding) which creates an unprefixed tree of non-overlapping intervals, where the length of each sequence is inversely proportional to the logarithm of the probability of that symbol needing to be encoded. The more likely it is that a symbol has to be encoded, the shorter its bit-sequence will be.

A tree is created, containing space for 288 symbols:

- 0–255: represent the literal bytes/symbols 0–255.

- 256: end of block – stop processing if last block, otherwise start processing next block.

- 257–285: combined with extra-bits, a match length of 3–258 bytes.

- 286, 287: not used, reserved and illegal but still part of the tree.

A match length code will always be followed by a distance code. Based on the distance code read, further "extra" bits may be read in order to produce the final distance. The distance tree contains space for 32 symbols:

- 0–3: distances 1–4

- 4–5: distances 5–8, 1 extra bit

- 6–7: distances 9–16, 2 extra bits

- 8–9: distances 17–32, 3 extra bits

- ...

- 26–27: distances 8,193–16,384, 12 extra bits

- 28–29: distances 16,385–32,768, 13 extra bits

- 30–31: not used, reserved and illegal but still part of the tree

For the match distance symbols 2–29, the number of extra bits can be calculated as ⌊ n 2 ⌋ − 1 {\displaystyle \left\lfloor {\frac {n}{2}}\right\rfloor -1} .

The two codes (the 288-symbol length/literal tree and the 32-symbol distance tree) are themselves encoded as [canonical Huffman codes](/source/Canonical_Huffman_code) by giving the bit length of the code for each symbol. The bit lengths are themselves [run-length encoded](/source/Run-length_encoding) to produce as compact a representation as possible. As an alternative to including the tree representation, the "static tree" option provides standard fixed Huffman trees. The compressed size using the static trees can be computed using the same statistics (the number of times each symbol appears) as are used to generate the dynamic trees, so it is easy for a compressor to choose whichever is smaller.

## Encoder–compressor

During the compression stage, it is the *encoder* that chooses the amount of time spent looking for matching strings. The zlib/gzip [reference implementation](/source/Reference_implementation) allows the user to select from a sliding scale of likely resulting compression-level vs. speed of encoding. Options range from 0 (do not attempt compression, just store uncompressed) to 9 representing the maximum capability of the reference implementation in zlib/gzip.

Other Deflate encoders have been produced, all of which will also produce a compatible [bitstream](/source/Bitstream) capable of being decompressed by any existing Deflate decoder. Differing implementations will likely produce variations on the final encoded bit-stream produced. The focus with non-zlib versions of an encoder has normally been to produce a more efficiently compressed and smaller encoded stream.

### Deflate64

Deflate64, specified by PKWARE, is a proprietary variant of Deflate. It's fundamentally the same algorithm. What has changed is the increase in dictionary size from 32 KB to 64 KB, an extension of the distance codes to 16 bits so that they may address a range of 64 KB, and the length code, which is extended to [16-bit](/source/16-bit_computing), so that it may define lengths of three to 65,538 bytes.[9] This leads to Deflate64 having a longer compression time, and potentially a slightly higher compression ratio, than Deflate.[10] Several free and/or open source projects support Deflate64, such as [7-Zip](/source/7-Zip),[11] while others, such as [zlib](/source/Zlib), do not, because the procedure is proprietary,[12] and the performance increase over Deflate is small.[13]

## Using Deflate in new software

Implementations of Deflate are freely available in many languages. Apps written in [C](/source/C_(programming_language)) typically use the [zlib](/source/Zlib) [library](/source/Library_(computing)) (under the permissive [zlib License](/source/Zlib_License)). Apps in [Borland Pascal](/source/Borland_Pascal) (and compatible languages) can use paszlib. Apps in [C++](/source/C%2B%2B) can take advantage of the improved Deflate library in [7-Zip](/source/7-Zip). Both [Java](/source/Java_(software_platform)) and [.NET](/source/.NET) framework offer out-of-the-box support for Deflate in their libraries (respectively, java.util.zip and [System.IO.Compression](https://docs.microsoft.com/en-us/dotnet/api/system.io.compression.deflatestream)). Apps in [Ada](/source/Ada_(programming_language)) can use [Zip-Ada](https://unzip-ada.sourceforge.net/) (pure) or [ZLib-Ada](https://zlib-ada.sourceforge.net/).

### Encoder implementations

- [PKZIP](/source/PKZIP): the first implementation, originally done by [Phil Katz](/source/Phil_Katz) as part of PKZip

- [zlib](/source/Zlib): standard reference implementation adopted in many apps because of its open-source, permissive license. See [Zlib § Forks](/source/Zlib#Forks) for higher-performance forks.

- [Crypto++](/source/Crypto%2B%2B): contains a public-domain implementation in [C++](/source/C%2B%2B) aimed at reducing potential [security vulnerabilities](/source/Vulnerability_(computing)). The author, Wei Dai states "This code is less clever, but hopefully more understandable and maintainable [than zlib]".

- [7-Zip](/source/7-Zip): written by Igor Pavlov in [C++](/source/C%2B%2B), this version is freely licensed and achieves higher compression than zlib at the expense of [central processing unit](/source/Central_processing_unit) (CPU) use. Has an option to use the Deflate64 storage format.

- [PuTTY](/source/PuTTY) 'sshzlib.c': a standalone implementation under the [MIT License](/source/MIT_License) by Simon Tatham, it has full decoding capability, but only supports static tree only creation

- libflate:[14] part of [Plan 9 from Bell Labs](/source/Plan_9_from_Bell_Labs), implements deflate compression

- [Hyperbac](/source/Red_Gate_Software#HyperBac): uses its own proprietary compression library (in C++ and assembly) with an option to implement the Deflate64 storage format

- [Zopfli](/source/Zopfli): C implementation under the [Apache License](/source/Apache_License) by [Google](/source/Google); achieves higher compression at the expense of CPU use. ZopfliPNG is a variant of Zopfli for use with [PNG](/source/Portable_Network_Graphics) files.

- igzip: an encoder written in the [x86 assembly language](/source/X86_assembly_language), released by [Intel](/source/Intel) under the [MIT License](/source/MIT_License). 3x faster than zlib -1. Useful for compressing genomic data.[15]

- libdeflate:[16] a library for fast, whole-buffer Deflate-based compression and decompression. Libdeflate is heavily optimized, especially on x86 processors.

AdvanceCOMP uses the higher compression ratio versions of Deflate in 7-Zip, libdeflate, and Zopfli to enable recompression of [gzip](/source/Gzip), [PNG](/source/Portable_Network_Graphics), [multiple-image Network Graphics](/source/Multiple-image_Network_Graphics) (MNG) and [ZIP](/source/ZIP_(file_format)) files with the possibility of smaller file sizes than zlib is able to achieve at maximum settings.[17]

### Hardware encoders

- AHA361-PCIX/AHA362-PCIX from [Comtech AHA](https://www.aha.com/) [Archived](https://web.archive.org/web/20061208005415/http://www.aha.com/) 2006-12-08 at the [Wayback Machine](/source/Wayback_Machine). Comtech produced a [PCI-X](/source/PCI-X) card (PCI-ID: 193f:0001) able to compress streams using Deflate at a rate of up to 3.0 Gbit/s (375 MB/s) for incoming uncompressed data. Accompanying the [Linux kernel](/source/Linux_kernel) [device driver](/source/Device_driver) for the AHA361-PCIX is an "ahagzip" utility and customized "mod_deflate_aha" able to use the hardware compression from [Apache](/source/Apache_HTTP_Server). The hardware is based on a [Xilinx](/source/Xilinx) [Virtex](/source/Virtex_(FPGA)) [field-programmable gate array](/source/Field-programmable_gate_array) (FPGA) and four custom AHA3601 [application-specific integrated circuits](/source/Application-specific_integrated_circuit) (ASICs). The AHA361/AHA362 boards are limited to only handling static Huffman blocks and require software to be modified to add support. The cards could not support the full Deflate specification, meaning they could only reliably decode their own output (a stream that did not contain any dynamic Huffman type 2 blocks).

- [StorCompress 300](https://web.archive.org/web/20080204071759/https://www.indranetworks.com/SC300.html)/[MX3](https://www.indranetworks.com/SCMX3.html) from [Indra Networks](https://www.indranetworks.com/). This is a range of [Peripheral Component Interconnect](/source/Peripheral_Component_Interconnect) (PCI, PCI-ID: 17b4:0011) or PCI-X cards featuring between one and six compression engines with claimed processing speeds of up to 3.6 Gbit/s (450 MB/s). A version of the cards are available with the separate brand *WebEnhance* specifically designed for web-serving use rather than [storage area network](/source/Storage_area_network) (SAN) or backup use; a [PCI Express](/source/PCI_Express) (PCIe) revision, the [MX4E](http://www.indranetworks.com/SCMX4E.html) is also produced.

- [AHA363-PCIe](https://web.archive.org/web/20080912222617/http://www.aha.com/show_prod.php?id=36)/[AHA364-PCIe](https://web.archive.org/web/20090212202014/http://www.aha.com/show_prod.php?id=37)/[AHA367-PCIe](https://web.archive.org/web/20090820184941/http://www.aha.com/show_prod.php?id=38). In 2008, Comtech started producing two PCIe cards (PCI-ID: 193f:0363/193f:0364) with a new hardware AHA3610 encoder chip. The new chip was designed to be capable of a sustained 2.5 Gbit/s. Using two of these chips, the AHA363-PCIe board can process Deflate at a rate of up to 5.0 Gbit/s (625 MB/s) using the two channels (two compression and two decompression). The AHA364-PCIe variant is an encode-only version of the card designed for out-going [load balancers](/source/Load_balancer) and instead has multiple register sets to allow 32 independent *virtual* compression channels feeding two physical compression engines. Linux, [Microsoft Windows](/source/Microsoft_Windows), and [OpenSolaris](/source/OpenSolaris) kernel device drivers are available for both of the new cards, along with a modified zlib system library so that dynamically linked applications can automatically use the hardware support without internal modification. The AHA367-PCIe board (PCI-ID: 193f:0367) is similar to the AHA363-PCIe but uses four AHA3610 chips for a sustained compression rate of 10 Gbit/s (1250 MB/s). Unlike the AHA362-PCIX, the decompression engines on the AHA363-PCIe and AHA367-PCIe boards are fully deflate compliant.

- [Nitrox](https://web.archive.org/web/20101203144755/http://www.cavium.com/processor_security_nitrox-III.html) and [Octeon](https://github.com/zerix/Cavium-SDK-2.0/tree/master/examples/zip)[*[permanent dead link](https://en.wikipedia.org/wiki/Wikipedia:Link_rot)*] processors from [Cavium, Inc.](https://cavium.com) contain high-speed hardware deflate and inflate engines compatible with both ZLIB and GZIP with some devices able to handle multiple simultaneous data streams.

- [HDL-Deflate](https://github.com/tomtor/HDL-deflate) GPL FPGA implementation.

- [ZipAccel-C](https://www.cast-inc.com/compression/gzip-lossless-data-compression/zipaccel-c/) from [CAST Inc](https://www.cast-inc.com/). This is a Silicon IP core supporting Deflate, [Zlib](/source/Zlib) and [Gzip](/source/Gzip) compression. ZipAccel-C can be implemented in [ASIC](/source/Application-specific_integrated_circuit) or [field-programmable gate array](/source/Field-programmable_gate_array) (FPGAs), supports both Dynamic and Static Huffman tables, and can provide throughputs in excess of 100 Gbit/s. The company offers compression/decompression accelerator board reference designs for Intel FPGA ([ZipAccel-RD-INT](https://www.cast-inc.com/compression/gzip-lossless-data-compression/gzip-rd-int/)) and Xilinx FPGAs ([ZipAccel-RD-XIL](https://www.cast-inc.com/compression/gzip-lossless-data-compression/gzip-rd-xil/)).

- [Intel Communications Chipset 89xx Series](/source/Intel_Xeon_chipsets) (Cave Creek) for the [Intel](/source/Intel) [Xeon](/source/Xeon) E5-2600 and E5-2400 Processor Series (Sandy Bridge-EP/EN) supports hardware compression and decompression using QuickAssist Technology. Depending on the chipset, compression and decompression rates of 5 Gbit/s, 10 Gbit/s, or 20 Gbit/s are available.[18]

- [IBM z15](/source/IBM_z15_(microprocessor)) CPUs incorporate an improved version of the Nest Accelerator Unit (NXU) hardware acceleration from the zEDC Express [input/output](/source/Input%2Foutput) (I/O) expansion cards used in z14 systems for hardware Deflate compression and decompression as specified by RFC1951.[19][20]

- Starting with the [POWER9](/source/POWER9) architecture, IBM added hardware support for compressing and decompressing Deflate (as specified by RFC 1951) to the formerly crypto-centric Nest accelerator (NX) core introduced with [POWER7](/source/POWER7)+. This support is available to programs running with [AIX](/source/IBM_AIX) 7.2 Technology Level 4 Expansion Pack or AIX 7.2 Technology Level 5 Service Pack 2 through the zlibNX library.[21][22]

## Decoder, decompressor

Inflate is the decoding process that takes a Deflate bitstream for decompression and correctly produces the original full-size data or file.

### Inflate-only implementations

The normal intent with an alternative Inflate implementation is highly optimized decoding speed, or extremely predictable [random-access memory](/source/Random-access_memory) (RAM) use for [microcontroller](/source/Microcontroller) [embedded systems](/source/Embedded_system).

- [Assembly](/source/Assembly_language) - [6502 inflate](https://github.com/pfusik/zlib6502), written by Piotr Fusik in [6502](/source/MOS_Technology_6502) assembly language. - [SAMflate](https://sourceforge.net/projects/samflate/), written by Andrew Collier in [Zilog Z80](/source/Zilog_Z80) assembly language with optional memory paging support for the [SAM Coupé](/source/SAM_Coup%C3%A9), and released under a combination of [software licenses](/source/Software_license): [Berkeley Software Distribution](/source/Berkeley_Software_Distribution) ([BSD](/source/BSD_licenses)), [GNU General Public License](/source/GNU_General_Public_License) (GPL), [GNU Lesser General Public License](/source/GNU_Lesser_General_Public_License) (LGPL), [Debian Free Software Guidelines](/source/Debian_Free_Software_Guidelines) (DFSG). - [gunzip](https://web.archive.org/web/20160304053236/https://bitbucket.org/grauw/gunzip), written by Laurens Holst in [Z80](/source/Zilog_Z80) assembly language for the [MSX](/source/MSX), licensed under [BSD](/source/BSD_licenses). - [inflate.asm](https://github.com/keirf/Amiga-Stuff), a fast and efficient implementation in [Motorola 68000](/source/Motorola_68000) machine language, written by Keir Fraser and released into the [public domain](/source/Public_domain).

- [C](/source/C_(programming_language)), [C++](/source/C%2B%2B) - [kunzip](https://web.archive.org/web/20070927122958/http://www.mikekohn.net/file_formats/kunzip.php) by Michael Kohn and unrelated to "KZIP". Comes with [C](/source/C_(programming_language)) [source code](/source/Source_code) under the [GNU Lesser General Public License](/source/GNU_Lesser_General_Public_License) (LGPL). Used in the GNU Image Manipulation Program ([GIMP](/source/GIMP)) installer. - puff.c ([zlib](/source/Zlib)), a small, unencumbered, single-file reference implementation included in the /contrib/puff directory of the zlib distribution. - [tinf](http://www.ibsensoftware.com/download.html) written by Jørgen Ibsen in [ANSI C](/source/ANSI_C) and comes with zlib license. Adds about 2k code. - [tinfl.c](https://code.google.com/p/miniz/source/browse/trunk/tinfl.c) ([miniz](https://code.google.com/p/miniz/)), Public domain Inflate implementation contained entirely in a single C function.

- PCDEZIP, Bob Flanders and Michael Holmes, published in [PC Magazine](/source/PCMag) 1994-01-11.

- [inflate.cl](http://opensource.franz.com/deflate/) by John Foderaro. Self-standing [Common Lisp](/source/Common_Lisp) decoder distributed with a [GNU Lesser General Public License](/source/GNU_Lesser_General_Public_License) (LGPL).

- [pyflate](http://www.paul.sladen.org/projects/pyflate/), a pure-[Python](/source/Python_(programming_language)) stand-alone Deflate ([gzip](/source/Gzip)) and [bzip2](/source/Bzip2) decoder by Paul Sladen. Written for research/prototyping and released under a combination of [software licenses](/source/Software_license): [Berkeley Software Distribution](/source/Berkeley_Software_Distribution) ([BSD](/source/BSD_licenses)), [GNU General Public License](/source/GNU_General_Public_License) (GPL), [GNU Lesser General Public License](/source/GNU_Lesser_General_Public_License) (LGPL), [Debian Free Software Guidelines](/source/Debian_Free_Software_Guidelines) (DFSG).

- [deflatelua](http://lua-users.org/wiki/ModuleCompressDeflateLua), a pure-[Lua](/source/Lua_(programming_language)) implementation of Deflate and [gzip](/source/Gzip)/zlib decompression, by David Manura.

- [inflate](https://github.com/chrisdickinson/inflate) a pure-[JavaScript](/source/JavaScript) implementation of Inflate by Chris Dickinson

- [pako](https://github.com/nodeca/pako): JavaScript speed-optimized port of zlib. Contains separate build with inflate only.

### Hardware decoders

- [Serial Inflate GPU](https://web.archive.org/web/20171010000403/http://www.bitsim.com/en/our-design-model/#Blocks) from BitSim. Hardware implementation of Inflate. Part of the Bitsim Accelerated Display Graphics Engine (BADGE) controller offering for embedded systems.

- [HDL-Deflate](https://github.com/tomtor/HDL-deflate) GPL FPGA implementation.

- [ZipAccel-D](https://www.cast-inc.com/compression/gzip-lossless-data-compression/zipaccel-d/) from [CAST Inc](https://www.cast-inc.com/). This is a Silicon IP core supporting decompression of Deflate, [Zlib](/source/Zlib) and [Gzip](/source/Gzip) files. The ZipAccel-D IP core that can be implemented in [ASIC](/source/Application-specific_integrated_circuit) or [FPGAs](/source/Field-programmable_gate_array). The company offers compression/decompression accelerator board reference designs for Intel FPGA ([ZipAccel-RD-INT](https://www.cast-inc.com/compression/gzip-lossless-data-compression/gzip-rd-int/)) and Xilinx FPGAs ([ZipAccel-RD-XIL](https://www.cast-inc.com/compression/gzip-lossless-data-compression/gzip-rd-xil/)).

- [IBM z15](/source/IBM_z15_(microprocessor)) CPUs incorporate an improved version of the Nest Accelerator Unit (NXU) hardware acceleration from the zEDC Express [input/output](/source/Input%2Foutput) (I/O) expansion cards used in z14 systems for hardware Deflate compression and decompression as specified by RFC1951.[19][20]

- Starting with the [POWER9](/source/POWER9) architecture, IBM added hardware support for compressing and decompressing Deflate (as specified by RFC 1951) to the formerly crypto-centric Nest accelerator (NX) core introduced with [POWER7](/source/POWER7)+. This support is available to programs running with [AIX](/source/IBM_AIX) 7.2 Technology Level 4 Expansion Pack or AIX 7.2 Technology Level 5 Service Pack 2 through the zlibNX library.[21][22]

## See also

- [List of archive formats](/source/List_of_archive_formats)

- [List of file archivers](/source/List_of_file_archivers)

- [Comparison of file archivers](/source/Comparison_of_file_archivers)

## Notes

1. **[^](#cite_ref-4)** Deflate is widely referenced as a compression algorithm, even though the specification (RFC 1951) defines it as a "data format". For example, the CompressionStream Web API specification uses the term "The DEFLATE algorithm".[3] In practice, the data format is the output of the algorithm, so neither definition is wrong.

## References

1. **[^](#cite_ref-1)** The Go Authors. ["flate package - compress/flate - Go Packages"](https://pkg.go.dev/compress/flate). *The Go Programming Language*. Google. Retrieved 5 September 2023. Package flate implements the Deflate compressed data format, described in RFC issue 1951.

1. **[^](#cite_ref-2)** ["PDF 32000-1:2008: Document management — Portable document format — Part 1: PDF 1.7"](https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandards/PDF32000_2008.pdf) (PDF). *Adobe Open Source*. [Adobe Inc.](/source/Adobe_Inc.) p. 23. Retrieved 5 September 2023. FlateDecode [...] Decompresses data encoded using the zlib/deflate compression method

1. **[^](#cite_ref-3)** ["Supported formats"](https://compression.spec.whatwg.org/#supported-formats). *WHATWG Compression*.

1. ^ [***a***](#cite_ref-IETF_5-0) [***b***](#cite_ref-IETF_5-1) [Deutsch, L. Peter](/source/L._Peter_Deutsch) (May 1996). [*Deflate Compressed Data Format Specification version 1.3*](https://www.rfc-editor.org/rfc/rfc1951#section-Abstract). [Internet Engineering Task Force](/source/Internet_Engineering_Task_Force) (IETF). p. 1. sec. Abstract. [doi](/source/Doi_(identifier)):[10.17487/RFC1951](https://doi.org/10.17487%2FRFC1951). [RFC](/source/Request_for_Comments) [1951](https://datatracker.ietf.org/doc/html/rfc1951). Retrieved 2014-04-23.

1. **[^](#cite_ref-patent_6-0)** [US patent 5051745](https://worldwide.espacenet.com/textdoc?DB=EPODOC&IDX=US5051745), [Katz, Phillip W.](/source/Phil_Katz), "String Searcher, and Compressor Using Same", published 1991-09-24, issued 1991-09-24, assigned to PKWare Inc.

1. **[^](#cite_ref-7)** Salomon, David (2007). [*Data Compression: The Complete Reference*](https://books.google.com/books?id=ujnQogzx_2EC&pg=PA241) (4 ed.). Springer. p. 241. [ISBN](/source/ISBN_(identifier)) [978-1-84628-602-5](https://en.wikipedia.org/wiki/Special:BookSources/978-1-84628-602-5).

1. **[^](#cite_ref-8)** [*Overall conventions*](https://www.rfc-editor.org/rfc/rfc1951#page-5). [IETF](/source/Internet_Engineering_Task_Force). p. 5. [doi](/source/Doi_(identifier)):[10.17487/RFC1951](https://doi.org/10.17487%2FRFC1951). [RFC](/source/Request_for_Comments) [1951](https://datatracker.ietf.org/doc/html/rfc1951).

1. **[^](#cite_ref-9)** [*Details of block format*](https://www.rfc-editor.org/rfc/rfc1951#page-9). [IETF](/source/Internet_Engineering_Task_Force). p. 9. [doi](/source/Doi_(identifier)):[10.17487/RFC1951](https://doi.org/10.17487%2FRFC1951). [RFC](/source/Request_for_Comments) [1951](https://datatracker.ietf.org/doc/html/rfc1951).

1. **[^](#cite_ref-10)** ["Binary Essence – Deflate64"](https://web.archive.org/web/20170621195505/http://www.binaryessence.com/dct/imp/en000225.htm). Archived from the original on 21 June 2017. Retrieved 22 May 2011.{{[cite web](https://en.wikipedia.org/wiki/Template:Cite_web)}}: CS1 maint: bot: original URL status unknown ([link](https://en.wikipedia.org/wiki/Category:CS1_maint:_bot:_original_URL_status_unknown))

1. **[^](#cite_ref-11)** ["Binary Essence – "Calgary Corpus" compression comparisons"](https://web.archive.org/web/20171227131819/http://www.binaryessence.com/dct/apc/en000263.htm). Archived from the original on 27 December 2017. Retrieved 22 May 2011.{{[cite web](https://en.wikipedia.org/wiki/Template:Cite_web)}}: CS1 maint: bot: original URL status unknown ([link](https://en.wikipedia.org/wiki/Category:CS1_maint:_bot:_original_URL_status_unknown))

1. **[^](#cite_ref-12)** ["-m (Set compression Method) switch"](https://web.archive.org/web/20220409225619/https://sevenzip.osdn.jp/chm/cmdline/switches/method.htm). *sevenzip.osdn.jp*. Archived from [the original](https://sevenzip.osdn.jp/chm/cmdline/switches/method.htm) on 2022-04-09. Retrieved 2023-01-21.

1. **[^](#cite_ref-13)** History of Lossless Data Compression Algorithms – [Deflate64](https://ieeeghn.org/wiki/index.php/History_of_Lossless_Data_Compression_Algorithms#DEFLATE64)

1. **[^](#cite_ref-14)** zlib FAQ – [Does zlib support the new "Deflate64" format introduced by PKWare?](https://www.zlib.net/zlib_faq.html#faq40)

1. **[^](#cite_ref-15)** ["Plan 9 from Bell Labs's /n/sources/plan9/sys/src/libflate"](https://web.archive.org/web/20060315063934/http://plan9.bell-labs.com/sources/plan9/sys/src/libflate/). *plan9.bell-labs.com*. Lucent Technologies. Archived from [the original](http://plan9.bell-labs.com/sources/plan9/sys/src/libflate/) on 2006-03-15.

1. **[^](#cite_ref-16)** ["High Performance Deflate Compression with Optimizations for Genomic Data Sets"](https://software.intel.com/en-us/articles/igzip-a-high-performance-deflate-compressor-with-optimizations-for-genomic-data). *Intel Software*. 1 October 2019. Retrieved 18 January 2020.

1. **[^](#cite_ref-17)** ["libdeflate"](https://github.com/ebiggers/libdeflate). *Heavily optimized library for DEFLATE/zlib/gzip compression and decompression*.

1. **[^](#cite_ref-18)** Mazzoleni, Andrea (21 February 2023). ["amadvance/advancecomp"](https://github.com/amadvance/advancecomp/blob/fcf71a89265c78fc26243574dda3a872574a5c02/doc/advzip.txt). *[GitHub](/source/GitHub)*.

1. **[^](#cite_ref-quickassist_19-0)** ["Intel Xeon Processor E5-2600 and E5-2400 Series with Intel Communications Chipset 89xx Series"](https://www-ssl.intel.com/content/www/us/en/intelligent-systems/crystal-forest-server/embedded-intel-xeon-e5-2600-and-e5-2400-series-with-intel-communications-chipset-89xx.html). Retrieved 2016-05-18.

1. ^ [***a***](#cite_ref-z15_announce_20-0) [***b***](#cite_ref-z15_announce_20-1) ["Introducing the IBM z15 - The enterprise platform for mission-critical hybrid multicloud"](https://www.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca&infotype=an&supplier=877&letternum=ENUSZG19-0041). *[IBM](/source/IBM)*. 12 September 2019. Retrieved 2021-11-01.

1. ^ [***a***](#cite_ref-z15_techmanual_21-0) [***b***](#cite_ref-z15_techmanual_21-1) Lascu, Octavian (28 April 2021). [*IBM z15 (8562) Technical Guide, Page 97*](https://books.google.com/books?id=0vr3DwAAQBAJ&dq=%22Nest+accelerator%22&pg=PA97). IBM Redbooks. [ISBN](/source/ISBN_(identifier)) [9780738458991](https://en.wikipedia.org/wiki/Special:BookSources/9780738458991). Retrieved 2021-11-01.

1. ^ [***a***](#cite_ref-zlibnx_22-0) [***b***](#cite_ref-zlibnx_22-1) ["Data compression by using the zlibNX library - IBM Documentation"](https://www.ibm.com/docs/en/aix/7.2?topic=management-data-compression-by-using-zlibnx-library). *[IBM](/source/IBM)*. Retrieved 2021-11-01.

1. ^ [***a***](#cite_ref-power7_accel_23-0) [***b***](#cite_ref-power7_accel_23-1) ["Exploitation of In-Core Acceleration of POWER Processors for AIX"](https://community.ibm.com/community/user/power/blogs/xinya-wang1/2021/02/18/exploitation-of-nest-accelerators-and-in-core-acce). Retrieved 2021-11-01.

## External links

- [PKWare](/source/PKWare), Inc.'s appnote.txt, [*.ZIP File Format Specification*](http://www.pkware.com/documents/casestudies/APPNOTE.TXT) [Archived](https://web.archive.org/web/20141205201932/http://www.pkware.com/documents/casestudies/APPNOTE.TXT) 2014-12-05 at the [Wayback Machine](/source/Wayback_Machine); Section 10, *X. Deflating – Method 8*.

- RFC [1951](https://www.rfc-editor.org/rfc/rfc1951) – *Deflate Compressed Data Format Specification version 1.3*

- [zlib Home Page](https://www.zlib.net)

- [*An Explanation of the Deflate Algorithm*](https://zlib.net/feldspar.html) – by Antaeus Feldspar

- [*Extended Application of Suffix Trees to Data Compression*](http://www.larsson.dogma.net/dccpaper.pdf) [Archived](https://web.archive.org/web/20160923065920/http://www.larsson.dogma.net/dccpaper.pdf) 2016-09-23 at the [Wayback Machine](/source/Wayback_Machine) – an excellent algorithm to implement Deflate by Jesper Larsson

- [Zip Files: History, Explanation and Implementation](https://www.hanshq.net/zip.html) – walk-through of a Deflate implementation

v t e Data compression methods Lossless type Entropy Adaptive coding Arithmetic Asymmetric numeral systems Golomb Huffman Adaptive Canonical Modified Range Shannon Shannon–Fano Shannon–Fano–Elias Tunstall Unary Universal Exp-Golomb Fibonacci Gamma Levenshtein Dictionary Byte-pair encoding Lempel–Ziv 842 LZ4 LZJB LZO LZRW LZSS LZW LZWL Snappy Other BWT CTW CM Delta Incremental DMC DPCM Grammar Re-Pair Sequitur LDCT MTF PAQ PPM RLE Hybrid LZ77 + Huffman Deflate LZX LZS LZ77 + ANS LZFSE LZ77 + Huffman + ANS Zstandard LZ77 + Huffman + context Brotli LZSS + Huffman LHA/LZH LZ77 + Range LZMA LZHAM RLE + BWT + MTF + Huffman bzip2 Lossy type Transform Discrete cosine transform DCT MDCT DST FFT Wavelet Daubechies DWT SPIHT Predictive DPCM ADPCM LPC ACELP CELP LAR LSP WLPC Motion Compensation Estimation Vector Psychoacoustic Audio Concepts Bit rate ABR CBR VBR Companding Convolution Dynamic range Latency Nyquist–Shannon theorem Sampling Silence compression Sound quality Speech coding Sub-band coding Codec parts A-law μ-law DPCM ADPCM DM FT FFT LPC ACELP CELP LAR LSP WLPC MDCT Psychoacoustic model Image Concepts Chroma subsampling Coding tree unit Color space Compression artifact Image resolution Macroblock Pixel PSNR Quantization Standard test image Texture compression Methods Chain code DCT Deflate Fractal KLT LP RLE Wavelet Daubechies DWT EZW SPIHT Video Concepts Bit rate ABR CBR VBR Display resolution Frame Frame rate Frame types Interlace Video characteristics Video quality Codec parts DCT DPCM Deblocking filter Lapped transform Motion Compensation Estimation Vector Wavelet Daubechies DWT Theory Compressed data structures Compressed suffix array FM-index Entropy Information theory Timeline Kolmogorov complexity Prefix code Quantization Rate–distortion Redundancy Symmetry Smallest grammar problem Community Hutter Prize People Mark Adler David A. Huffman Phil Katz

---
Adapted from the Wikipedia article [Deflate](https://en.wikipedia.org/wiki/Deflate) by Wikipedia contributors ([contributor history](https://en.wikipedia.org/wiki/Deflate?action=history)). Available under [Creative Commons Attribution-ShareAlike 4.0 International](https://creativecommons.org/licenses/by-sa/4.0/). Changes may have been made.