DEFLATE Compression
DEFLATE compression is the lossless data compression algorithm specified by RFC 1951 (1996) and the default compression method used inside ZIP archives. Designed by Phil Katz for PKZIP, it compresses data by combining two stages: LZ77, which eliminates redundancy by replacing repeated byte sequences with back-references, and Huffman coding, which then packs the resulting symbols into variable-length codes weighted by frequency.
DEFLATE is lossless: the decompressed output is byte-for-byte identical to the input. It is also the algorithm behind gzip (.gz) and the PNG image format, which is why a single well-tested implementation — typically zlib — ships in nearly every operating system, browser, and runtime.
How DEFLATE works: LZ77 then Huffman
DEFLATE runs the input through two sequential stages. The first is LZ77, a dictionary-based technique that scans the data over a sliding window of up to 32 KB. Whenever it finds a byte sequence that has already appeared within that window, it replaces the repeat with a (distance, length) pair — a back-reference saying "copy length bytes from distance bytes back." The window caps how far back a match can reach (32 KB) and a match can copy at most 258 bytes. Sequences with no match pass through as literal bytes. The output of this stage is a stream of tokens: literals and match references.
The second stage is Huffman coding, an entropy encoder. It assigns variable-length bit codes to each symbol so that frequently occurring symbols (common bytes, common match lengths) get short codes and rare symbols get long codes. DEFLATE supports two flavors: a fixed Huffman table baked into the spec, and a dynamic table transmitted in the compressed stream and tuned per block. The compressor picks whichever yields the smaller output for each block. The stream is divided into blocks, each independently tagged as stored (raw, uncompressed), fixed-Huffman, or dynamic-Huffman, and ending once a final-block flag is set.
Why ZIP uses DEFLATE
DEFLATE won the ZIP default because it hits a strong three-way balance: a decent compression ratio, fast decompression, and effectively universal decoder support. Decompression is particularly cheap — a single linear pass that resolves back-references and walks a Huffman tree — which is why browsers can inflate streamed archives on the fly and why it remains the lingua franca of compressed payloads. ZIP entries record the method per-file in a header: method 8 means DEFLATE, method 0 means Stored (no compression). There is no in-archive switch to pick a different algorithm.
A few DEFLATE variants exist. Deflate64 (method 9) widens the sliding window to 64 KB and raises the maximum match length, yielding a marginally better ratio; it is a proprietary PKWARE extension used mostly by Windows Explorer for large archives and is rare elsewhere. DeflateFast refers to faster compressor strategies that still emit standard DEFLATE output, not a separate format. Anything claiming to read .zip must support plain DEFLATE; the others are optional.
Modern alternatives that beat DEFLATE
DEFLATE is a 1996 design, and several newer algorithms improve on it on either ratio or speed:
- zstd (Zstandard) — roughly matches DEFLATE's ratio while being dramatically faster to both compress and decompress, with tunable levels. It is the modern default for streaming and storage where both speed and ratio matter.
- brotli — achieves a better ratio than DEFLATE, especially on web text (HTML, JS, CSS), with a large built-in dictionary. It is widely supported in browsers for content encoding but not used in ZIP.
- LZMA / LZMA2 — used in 7z and
.xz, it reaches a noticeably better ratio than DEFLATE at the cost of much slower compression and decompression. It is the go-to when size matters more than time.
Why .7z and .zst exist as separate formats
The ZIP container fixes the per-entry compression method to a short list that starts at DEFLATE and Stored. You generally cannot tell an existing .zip to use LZMA or zstd instead — the decoder on the other end would not recognize the method ID. To ship LZMA-compressed data you use .7z (or .xz for a single stream); to ship zstd-compressed data you use .zst (or .tar.zst). Each archive format carries its own metadata and method set, which is why compression algorithm choice is effectively a format choice rather than a ZIP option.
Frequently asked questions
What is DEFLATE compression?
DEFLATE is the lossless compression algorithm defined by RFC 1951 and used as the default method in ZIP files. It combines LZ77 — which replaces repeated byte sequences over a 32 KB sliding window with (distance, length) back-references — with Huffman coding, which encodes the resulting symbols using variable-length codes so frequent symbols get short codes. It is also the algorithm behind gzip and PNG.
Is DEFLATE lossless?
Yes. DEFLATE is strictly lossless: the decompressed output is byte-for-byte identical to the original input. It only exploits statistical redundancy in the data, never discards information, and ZIP stores a CRC-32 checksum per entry so integrity can be verified after extraction. That CRC catches accidental corruption; it is not a cryptographic check and is trivial to forge.
What is the difference between DEFLATE and LZMA?
Both are lossless, but LZMA (used in 7z and .xz) uses a much larger dictionary and more sophisticated modeling, so it achieves a noticeably better compression ratio than DEFLATE. The tradeoff is speed: LZMA compresses and decompresses much more slowly. DEFLATE wins on decompression speed and universal support; LZMA wins when the smallest output matters most.
Why does ZIP use DEFLATE instead of newer algorithms?
DEFLATE was standardized in 1996 and became the ZIP default because it offers a good balance of compression ratio, fast decompression, and near-universal decoder support. Newer algorithms like zstd and brotli beat it on speed or ratio, but the ZIP format locks the per-entry method to a small set (mainly DEFLATE and Stored), so adopting a better algorithm requires a different container, such as .7z for LZMA or .zst for zstd.
What is Deflate64 and is it different from DEFLATE?
Deflate64 is a proprietary PKWARE extension of DEFLATE (ZIP method 9) that widens the sliding window from 32 KB to 64 KB and increases the maximum match length, giving a marginally better compression ratio. It is rare outside Windows Explorer, which uses it for large archives. Standard DEFLATE (method 8) remains the universally supported variant that every ZIP reader must handle.