Standards 7 min read 16 October 2026

PDF Compression Algorithms: Flate, JPEG, JPEG2000, JBIG2, and LZW Explained

PDF supports multiple compression algorithms for different content types. Choosing the right one — or combining them — is the key to balancing file size and quality. This guide explains how Flate, JPEG, JPEG2000, JBIG2, CCITTFax, and LZW work inside PDF, when each is appropriate, and how they combine in optimised PDF workflows.

A PDF file is not a monolithic block of data — it is a structured container of objects, each of which may be individually compressed using a different algorithm. Understanding which compression algorithm is applied where, and why different algorithms suit different content types, is the key to producing PDFs that are both small and high quality. The PDF specification supports a rich set of compression filters, each optimised for specific data characteristics. Using JPEG for text rasterisations introduces visible artefacts; using Flate for photographic images produces files far larger than JPEG. The right combination of algorithms — applied at the right quality settings, to the right content types — can reduce a naive PDF's size by 70–90% without any visible quality difference.

How PDF compression works: filters and filter chains

In PDF, every stream object (content streams, image data, font data, embedded files) can have a /Filter entry specifying one or more compression filters to apply when decoding the stream. A filter chain applies filters in sequence: /Filter [/ASCII85Decode /FlateDecode] means the data was first Flate-compressed, then ASCII85-encoded (the reverse order of how the chain is read — filters are listed in decoding order). Each filter has a corresponding decoder that the PDF reader applies when reading the stream. Common filter names: - /FlateDecode: Deflate/zlib compression (Flate) - /DCTDecode: JPEG compression - /JPXDecode: JPEG2000 compression - /JBIG2Decode: JBIG2 bi-level compression - /CCITTFaxDecode: CCITT Group 3/4 fax compression - /LZWDecode: LZW compression (legacy, largely replaced by Flate) - /ASCII85Decode: ASCII85 encoding (not compression — converts binary to printable ASCII) - /RunLengthDecode: Simple run-length encoding (rarely useful in practice) The /DecodeParms entry provides parameters for the filter (e.g., JPEG quality, Flate predictor, CCITT encoding mode).

Flate (Deflate/zlib): the workhorse for non-image data

Flate (/FlateDecode) is based on the DEFLATE algorithm — the same algorithm used in ZIP files, gzip, and PNG images. It is a lossless compressor that works by finding repeated byte sequences and encoding them as back-references. **Where Flate excels in PDF**: - **Content streams** (page drawing instructions): Content streams contain many repeated operator sequences (font selection, colour setting, position moves). Flate typically achieves 3:1 to 10:1 compression on content streams. - **Font data** (Type 1, TrueType, OpenType): Font programs have repetitive structure that compresses well. Flate reduces typical font stream sizes by 50–70%. - **Metadata streams** (XMP, docinfo): XML-structured metadata compresses extremely well with Flate due to repeated tag names and attribute strings. - **Object streams**: When PDF 1.5+ object streams are Flate-compressed, the combined dictionary data for many small objects can compress at ratios of 5:1 to 15:1. **Flate predictor**: For structured binary data (like raw image pixel arrays), a predictor filter applied before Flate improves compression by differencing adjacent values before encoding. PNG-style predictors (filter type 15, values 10–15) are commonly used for raw image data in PDF. Flate is lossless — the decoded data is byte-for-byte identical to the input — making it the only appropriate choice for text, drawings, and any content where data integrity is required.

JPEG (DCT): the standard for photographic images

/DCTDecode implements JPEG compression using Discrete Cosine Transform (DCT). JPEG is a lossy algorithm — it irreversibly discards high-frequency image information that the human visual system is least sensitive to, achieving much higher compression ratios than lossless methods for photographic content. **JPEG quality settings in PDF**: The /DecodeParms dictionary for DCTDecode allows specifying JPEG quality. However, most PDF generators embed pre-compressed JPEG data directly rather than passing quality parameters — the quality was set when the JPEG was created, not at PDF embed time. For maximum control, export images from Photoshop at the desired quality, then embed in the PDF. **When to use JPEG in PDF**: Photographs, gradients, complex illustrations with smooth colour transitions. Aim for quality 80–90% for print, 60–75% for screen-only distribution. **When NOT to use JPEG**: Text, line art, diagrams with flat colours, screenshots with sharp edges, logos. JPEG's block artefacts at 8×8 pixel boundaries are highly visible on sharp edges and make text look blurry. Use Flate (via PNG or as a raw losslessly-compressed image) for these content types. **The recompression trap**: If a JPEG image is embedded in a PDF and then the PDF is processed through a tool that re-encodes all images as JPEG, the image is compressed twice — each generation introduces additional quality loss. Use tools with lossless JPEG pass-through (like qpdf) to avoid this.

JPEG2000 (JPX): superior quality at lower sizes

/JPXDecode implements JPEG2000 compression using the Discrete Wavelet Transform. JPEG2000 achieves higher compression ratios than JPEG at equivalent visual quality, avoids the 8×8 block artefact problem, and supports both lossy and lossless modes in a single format. **Why JPEG2000 is not ubiquitous in PDF**: Despite its technical superiority, JPEG2000 adoption in PDF is limited: - **Encoding speed**: JPEG2000 encoding is significantly slower than JPEG — a consideration for real-time document processing pipelines - **Tool support**: Not all PDF generators support JPEG2000 output; not all PDF readers decode it correctly (though all modern readers do) - **PDF/A-2+ requirement**: PDF/A-2 and PDF/A-3 permit JPEG2000 — this is one of PDF/A-2's key advantages over PDF/A-1 for scanned document archives where JPEG2000 provides better size-to-quality ratios than JPEG for greyscale document images **Use cases**: Scanned document archives (greyscale medical images, historical document digitisation), geospatial imagery in PDF/E documents, any high-volume image storage where the encoding time cost is amortised across many reads.

JBIG2 and CCITTFax: bi-level image compression

Bi-level (black-and-white, 1 bit per pixel) images — scanned text pages, fax transmissions, engineering drawings — require specialised compression that exploits their binary nature. **JBIG2** (/JBIG2Decode): A modern bi-level compression standard that achieves extraordinary compression ratios on scanned text pages by identifying repeated symbols (letter shapes) and encoding each occurrence as a reference to a shared symbol dictionary. A page of black-and-white scanned text at 300 DPI that is 800 KB as uncompressed bitmap may compress to 15–30 KB with JBIG2 — a 25:1 ratio. JBIG2 supports both lossless mode (exact pixel reproduction) and lossy mode (symbol matching tolerance, similar-looking characters are treated as identical — acceptable for archiving but risks occasional character substitution errors). **CCITTFax** (/CCITTFaxDecode): The compression algorithm used in fax transmissions, based on CCITT Group 3 (1D) and Group 4 (2D) encoding. Less efficient than JBIG2 but more universally supported and with a longer track record. Used in PDF/A-1 contexts where JBIG2 may not be acceptable. For the PDF/A archiving context, JBIG2 lossless mode is permitted in PDF/A-2 and PDF/A-3 but not PDF/A-1 (which restricts compression to CCITT and JPEG).

Choosing the right algorithm: a decision guide

A practical content-type-to-algorithm mapping: | Content type | Recommended filter | Notes | |---|---|---| | Photographic colour images | DCTDecode (JPEG) | Quality 80–90% for print, 65–75% for screen | | Photographic greyscale images | DCTDecode or JPXDecode | JPEG2000 for archiving, JPEG for compatibility | | Scanned text pages (bi-level) | JBIG2Decode | Lossless mode for critical documents | | Scanned text pages (greyscale) | DCTDecode | High quality (85+) to keep text sharp | | Diagrams and line art | FlateDecode | Always lossless for sharp edges | | Vector content streams | FlateDecode | Content streams benefit greatly from Flate | | Font programs | FlateDecode | Lossless required for font data | | Metadata/XML | FlateDecode | Excellent compression on structured text | For the best results across a full document, a mixed-algorithm approach is needed — losslessly-compressed content streams alongside JPEG images alongside JBIG2 text scans. PDF optimisation tools (Acrobat Pro's PDF Optimizer, Ghostscript with custom settings, qpdf) can apply these different algorithms to different object types in a single pass.

Compression algorithm selection is one of the highest-leverage decisions in PDF optimisation. The difference between the wrong algorithm (JPEG on text, Flate on photos) and the right one can be a factor of 10 in file size at equivalent quality. For production PDF workflows, invest in configuring your PDF generator's compression settings correctly — the time spent optimising those settings pays dividends across every document produced. Use our PDF compression tool for immediate browser-based size reduction without configuring algorithms manually.

Frequently asked questions

Why does Acrobat's PDF Optimizer have separate settings for different image types?

Because different image types have different optimal compression algorithms. Acrobat's PDF Optimizer (File > Save As Other > Optimized PDF) separates "Color Images", "Grayscale Images", and "Monochrome Images" because photographs need JPEG/JPEG2000 (lossy), greyscale document scans may use JPEG or ZIP, and black-and-white images should use JBIG2 or CCITT Fax. Using JPEG on monochrome images produces artefacts; using CCITT on colour photos produces enormous file sizes. The separate panels let you apply the right algorithm to each type.

What is the difference between lossless and lossy compression in PDF?

Lossless compression (Flate/deflate, CCITT, JBIG2 lossless, LZW) reconstructs the original data exactly — the decoded bytes are identical to the input. Lossy compression (JPEG/DCT, JPEG2000 lossy, JBIG2 lossy) irreversibly discards information to achieve higher compression ratios — the decoded data is close to the original but not identical. For text, line art, and font data, lossless compression is required. For photographic images distributed for screen viewing or general print, lossy JPEG at appropriate quality is standard. For archival use (PDF/A), images must be stored with sufficient quality that the document remains visually reproducible — high-quality JPEG (85+) or lossless compression is recommended.

Why is LZW no longer commonly used in PDF?

LZW was the primary compression algorithm in early PDF (PDF 1.0–1.1) because it was already used in PostScript and GIF images. However, LZW was encumbered by Unisys/IBM patents (the patents expired around 2003–2004, but the uncertainty discouraged use for years). Adobe introduced FlateDecode (based on the unencumbered DEFLATE algorithm) in PDF 1.2 as a replacement. Flate compresses slightly better than LZW in most cases and has no patent concerns. Modern PDF generators use Flate exclusively; LZW support in readers is maintained for backward compatibility with old files.

Does recompressing a PDF lose image quality?

Only if the recompression uses a lossy algorithm (JPEG). If a PDF with JPEG images is passed through a tool that re-encodes all images as JPEG (even at the same quality setting), each encode-decode cycle introduces additional loss — this is called "generation loss". To avoid this, use a tool that passes JPEG data through unchanged (lossless JPEG pass-through) like qpdf, or configure your processing tool to skip recompression of images that are already at or below the target quality. Flate and other lossless algorithms can be applied and removed without any quality impact.

Try it yourself

Everything in this article can be done directly in the free PDFTheGuide editor — no account required.

Compress PDF Edit PDF Merge PDF Open editor