LZMA and LZMA2: high-ratio compression for 7z
LZMA (Lempel-Ziv-Markov chain Algorithm) is the lossless compression method used by the 7z format and by the standalone .xz container. It belongs to the same dictionary coding family as DEFLATE — an LZ77-style stage that emits back-references — but it is engineered for a much better compression ratio at the cost of far more compression and decompression time.
If DEFLATE is the fast, universal default, LZMA is the choice when the smallest output matters most. It is the algorithm behind the famously small 7z archives and the .tar.xz packages common in Linux distributions. LZMA2 is a thin chunked container around LZMA that adds random access and stored (uncompressed) chunks without changing the core algorithm.
How LZMA beats DEFLATE
LZMA improves on DEFLATE on three axes at once. First, a much larger dictionary: where DEFLATE’s sliding window is 32 KB, LZMA’s can be tens or hundreds of megabytes, so it finds matches across a far longer range of input. Second, a smarter match search (heavy hash-chain and match-length modeling) that finds longer, better matches rather than settling for the first one. Third, and most importantly, it replaces Huffman with range coding — a form of arithmetic coding — driven by context models that predict the next symbol from recent history.
That last point is the real lever. Huffman coding encodes one whole symbol per output code, which is provably optimal only under that constraint. Range coding can encode symbols to a fractional number of bits by modeling probabilities conditionally, so it squeezes the token stream harder than Huffman ever can. The Markov-style context modeling in the name is exactly that: the probability of each bit is estimated from the bits and matches seen just before it.
What LZMA2 adds
LZMA2 wraps raw LZMA in a chunked format. The input is split into blocks, each independently compressed (or, if it does not shrink, stored uncompressed as a Store-style chunk), with a small header giving each block’s type and size. Two practical benefits follow: a reader can decompress chunks in parallel for speed, and a chunk that fails to compress can be stored verbatim instead of growing the output. The core LZMA algorithm inside each chunk is unchanged.
This is why modern 7z and .xz files are described as "LZMA2" rather than "LZMA" — the container got smarter while the engine stayed the same. The chunking is invisible to the user; it only shows up as faster multi-threaded decompression and better handling of mixed compressible and incompressible data.
The ratio-vs-speed tradeoff
LZMA’s gains are not free. Its compression is dramatically slower than DEFLATE at comparable settings, because the larger dictionary and thorough match search cost real CPU, and the range coder’s probability models must be maintained bit by bit. Decompression is also slower than DEFLATE, though far less lopsided than compression — inflating LZMA is still a linear pass, just a heavier one. For distributing software, documentation, or archives where size dominates, that is an excellent trade. For interactive use where you compress and immediately throw away the result, DEFLATE or zstd is usually the better pick.
This is also why ZIP did not simply adopt LZMA as its default. The ZIP container locks the per-entry method to a small set (mainly DEFLATE and Stored), and adopting LZMA would require every decoder to support it. Instead, LZMA lives in formats designed around it: 7z (where it is the flagship method) and .xz for single-stream use.
LZMA, 7z, and solid archives
LZMA’s large dictionary pays off most when it can see a lot of data at once, which is why 7z typically compresses many files together as a [solid archive](/glossary/solid-archive) rather than entry-by-entry like ZIP. Solid compression lets the dictionary find matches *across* files — repeated headers, duplicated code, shared boilerplate — which per-entry DEFLATE can never see. The combination of LZMA + solid + large dictionary is what produces 7z’s standout ratios. See what is a 7z file for the format-level picture.
Frequently asked questions
What is LZMA compression?
LZMA (Lempel-Ziv-Markov chain Algorithm) is a lossless compression method used by the 7z format and .xz files. It is an LZ77-family dictionary coder like DEFLATE, but with a much larger dictionary, more thorough match search, and range (arithmetic) coding with context modeling instead of Huffman — all of which yield a better compression ratio at the cost of much slower compression.
What is the difference between LZMA and DEFLATE?
Both are lossless LZ77-family compressors, but DEFLATE uses a 32 KB window and Huffman entropy coding and is fast and universal, while LZMA uses a much larger window, heavier match search, and range coding with context modeling to reach a noticeably better ratio at far higher CPU cost. ZIP’s default is DEFLATE; 7z and .xz use LZMA.
What is LZMA2?
LZMA2 is a chunked container around the LZMA algorithm. It splits input into blocks, each compressed (or stored uncompressed if it does not shrink) with a small header. This adds parallel decompression and lets incompressible chunks be stored verbatim, without changing the core LZMA engine. Modern 7z and .xz files use LZMA2.
Why is LZMA slower than DEFLATE?
Because its gains cost CPU: a much larger dictionary to search, a more thorough match-finding strategy, and a range coder whose probability models are updated bit by bit. Decompression is also slower than DEFLATE, though far less lopsided than compression. The payoff is a better ratio, which is worth it for distribution archives where size dominates.
Does ZIP use LZMA?
Not as its default. ZIP locks the per-entry compression method to a small set (mainly DEFLATE and Stored), and adopting LZMA would require every decoder to support it. LZMA lives in formats designed around it instead — 7z, where it is the flagship method, and .xz for single-stream use. To ship LZMA-compressed data you use one of those containers rather than a plain .zip.