TIFF compression types — none, packbits, LZW, deflate, JPEG, CCITT

TIFF's compression tag has dozens of registered values. In practice, only seven or eight are common. The codec used in the source TIFF affects how the conversion handles it and how big the resulting PDF will be.

How conversion treats the source codec

The conversion pipeline decodes the TIFF's pixel data and re-embeds it in the PDF — almost always with Flate (zlib) compression, regardless of the source codec. This is correct visually but typically produces a PDF 2–3× larger than what specialized pass-through utilities produce, where CCITT or JPEG bitstreams enter the PDF unchanged.

The trade-off: a decode-then-re-embed pipeline handles every TIFF variant in the wild, including unusual color spaces, exotic strip layouts, and proprietary scanner extensions. Pure pass-through requires a much narrower input subset.

Compression 1 — none

Raw pixels, no compression. Used when the TIFF was generated quickly (live capture, real-time output) and didn't pause to compress. Files are large; the resulting Flate-compressed PDF is dramatically smaller (50–95% size reduction).

Compression 2/3/4 — CCITT

Bitonal compression. See the dedicated CCITT post for details. The source TIFF is small (typically 50 KB per page); the resulting PDF is larger because the bitonal pixels are decoded and re-embedded with a Flate-compressed grayscale filter rather than the CCITT bitstream being passed through. For maximum size efficiency on bitonal scans, use specialist archival software that explicitly preserves CCITT inside the PDF.

Compression 5 — LZW

The classic TIFF lossless compression, popular in the 1990s before deflate became standard. LZW (Lempel-Ziv-Welch) was patented by Unisys until 2003, which slowed adoption — TIFF tools had to either license the patent or use a different algorithm.

LZW is competitive with deflate on TIFF-typical content (slightly better on text scans, slightly worse on photographic content). Modern TIFFs from professional tools (Photoshop, scanner drivers) often default to LZW for backwards compatibility.

PDF supports LZW via /LZWDecode, but the variant differs slightly from TIFF's. In the conversion, the source LZW data is decoded and the pixels are re-embedded with /FlateDecode. Pixel data is preserved exactly; file size is similar.

Compression 7 — JPEG-in-TIFF

The "modern" JPEG-in-TIFF (added in the TIFF 6.0 specification supplement, mid-1990s; sometimes called "Type 7"). JPEG-compressed strips inside a TIFF container. Used for scanned color photos when the user wants TIFF's multi-page flexibility but doesn't need lossless quality.

An ideal converter would pass the compressed JPEG bytes through to PDF as /DCTDecode. The general-purpose conversion behind TIFF2PDF instead decodes the JPEG and re-embeds the pixels — the result is visually identical (lossy → lossy is generally lossless if quality is preserved, but small color-space conversions may apply). Output size is typically similar to input — JPEG-in-TIFF and JPEG-in-PDF are roughly equivalent encodings.

Compression 8 — Deflate

Same algorithm as PNG and PDF: zlib's deflate with optional row predictor. Added to TIFF in the late 1990s as a patent-free alternative to LZW.

Deflate on TIFF and deflate in PDF are the same family of algorithms; pixel data is preserved exactly through conversion, with similar output size to input.

Compression 32773 — PackBits RLE

An Apple-designed run-length encoding from the 1980s. Simple: each run of bytes is preceded by a count byte (positive for literal runs, negative for repeated bytes). Compresses synthetic content well, photographic content poorly.

Found in TIFFs from older Macintosh tools (1990s desktop publishing) and some niche imaging hardware. PDF doesn't support PackBits as a filter; conversion decodes PackBits and re-embeds with /FlateDecode. File size typically drops by 30–50% in the conversion (deflate is more efficient than PackBits for typical content).

Compression 6 — Old JPEG (the cursed one)

An earlier, broken JPEG-in-TIFF design that predates the TIFF 6.0 supplement. Multiple incompatible implementations exist; some tools wrote files that don't conform to any documented spec. The format was officially deprecated in 1995 but still appears occasionally in old archives.

Old JPEG TIFFs typically fail to convert — the underlying conversion library declines to guess at decoding ill-specified files. If you have one, re-save it as a modern JPEG-in-TIFF using a dedicated TIFF utility before uploading.

Rare and exotic compression types

• JBIG (compression 9, 10): bitonal compression similar to JBIG2. Rare; the conversion library typically lacks a JBIG decoder, so these files don't convert.
• ZSTD (compression 50000): Facebook's modern codec, faster and slightly better than deflate. Some scientific imaging tools use it. PDF doesn't support ZSTD natively.
• WebP (compression 50001): WebP-encoded strips inside TIFF. Niche; rarely supported by general-purpose TIFF tooling.
• Custom codes (32768+): vendor-specific. Pixar, Adobe, and others have allocated ranges. Generally not handled outside the vendor's own software.

Files using these codecs will typically fail to convert. Re-save the TIFF with a standard codec (LZW, Deflate, or G4) before uploading.

How to check a TIFF's compression

Open the TIFF in a full-featured image viewer or editor (Photoshop, GIMP, IrfanView on Windows). The "Image Properties" or "File Info" panel reports the compression name (e.g. "Group4", "LZW", "JPEG") and the photometric interpretation (e.g. "WhiteIsZero" for fax-style bilevel). On Mac, "Get Info" on a TIFF file shows basic properties; specialized tools show more.