The ten standard filters a stream’s data can be encoded with, their parameters, and how a stream dictionary names them.
JPXDecode and Crypt came in PDF 1.5. PDF 2.0 added no filters and deprecated none.
A stream’s data can be stored encoded: compressed, written out as ASCII text, or encrypted. The stream dictionary’s/Filter entry names the decoders a reader runs to get the original bytes back. Filters only deal in bytes: FlateDecode works the same on a page’s content, a font or an image, and what the decoded bytes mean depends on the kind of stream. Streams and filters on the Objects page in Learning introduces them.
There are two kinds. ASCII filters turn text back into binary data. They make a file larger, and exist so binary data can pass through channels that only carry 7-bit text; in an encrypted file they gain nothing, since encryption makes the data binary again. Decompression filters make it smaller, and the lossy ones are only for images, where an approximation of the original is acceptable. A version badge marks a filter added after PDF 1.0.
Where filters are named
Any stream dictionary can have these entries:
| Key | Value |
|---|---|
/Lengthinteger | Required. The number of bytes between stream and endstream: the data as stored, so after encoding. |
/Filtername or array | The filter that decodes the data, or an array of filters in the order the reader applies them. |
/DecodeParmsdictionary or array | The filters’ parameters: one dictionary for a single filter, or an array with one entry per filter, null for a filter that uses its defaults. Can be left out when every parameter has its default value. |
/Ffile specification | An external file that holds the data instead. The bytes between stream and endstream are then ignored; usually there are none and /Length is 0. |
/FFiltername or array | The filters for the external file’s data, used instead of /Filter. |
/FDecodeParmsdictionary or array | Their parameters, used instead of /DecodeParms. |
/DLinteger | The length of the decoded data in bytes. Only a hint: for some filters it can’t be known exactly. |
/Filter can be an array, a chain of filters. The writer encodes in one order, and the array lists the decoders in the order the reader runs them, which is the reverse. This content stream was compressed with Flate and the result written out as ASCII85 text, so ASCII85Decode comes first:
5 0 obj << /Length 78 /Filter [/ASCII85Decode /FlateDecode] >> stream GhOZI0[MUU.-E?E;D:$`:rlWj2),*;EYO*kJn>cP5nFDNBEf806O9-r"\fP[ 7W:X<LgV>*//oAt~> endstream endobj
ASCII85Decode skips the line break, stops at ~> and returns 60 bytes of zlib data.FlateDecode turns those into the 114 bytes of the content stream:
q 0.5 w 72 700 m 540 700 l S 72 680 m 540 680 l S 72 660 m 540 660 l S 72 640 m 540 640 l S 72 620 m 540 620 l S Q
/Length counts the bytes as stored: 75 characters for the 60 bytes, 2 for ~> and 1 for the line break. With a chain, /DecodeParms is an array in the same order as /Filter, withnull for each filter that uses its defaults:
<< /Length … /Filter [/ASCII85Decode /FlateDecode] /DecodeParms [null << /Predictor 12 /Columns 4 >>] >>
From PDF 1.2 a stream’s data can live in a separate file named by /F. Then /FFilter and /FDecodeParms take the place of /Filter and /DecodeParms, with the same rules. Data in an external file is never encrypted, since it isn’t part of the PDF file.
The standard filters
In the order the specifications list them. Under each name is its abbreviation in inline images, if it has one.
| Filter | What it does | Added |
|---|---|---|
ASCIIHexDecodeInline: AHx | Turns pairs of hexadecimal digits back into bytes. White space is skipped, > marks the end, and a lone last digit is read as if a 0 followed it. The text is twice the size of the bytes it holds.Lossless · any data · No parameters1.4 §3.3.1 · 1.7 §7.4.2 | |
ASCII85DecodeInline: A85 | Turns base-85 text back into bytes: each group of five characters from ! to u gives four bytes, z stands for four zero bytes, and ~> marks the end. The text is a quarter larger than the bytes it holds, so it beats hex.Lossless · any data · No parameters1.4 §3.3.2 · 1.7 §7.4.3 | |
LZWDecodeInline: LZW | Decompresses LZW (Lempel-Ziv-Welch), the method TIFF uses: codes of 9 to 12 bits that point into a table of byte sequences the decoder builds as it reads. Flate usually compresses better, and writers have mostly moved to it.Lossless · any data · Parameters1.4 §3.3.3 · 1.7 §7.4.4 | |
FlateDecodeInline: Fl | Decompresses zlib data: deflate (RFC 1951), the compression ZIP and PNG use, in a zlib wrapper (RFC 1950). The usual choice for content streams, fonts, object streams and images that must stay exact.Lossless · any data · Parameters1.4 §3.3.3 · 1.7 §7.4.4 | |
RunLengthDecodeInline: RL | Expands a simple run-length code. A length byte from 0 to 127 is followed by 1 to 128 bytes to copy as they are; 129 to 255 is followed by one byte to repeat 2 to 128 times; 128 marks the end.Lossless · any data, best with long runs of one byte value · No parameters1.4 §3.3.4 · 1.7 §7.4.5 | |
CCITTFaxDecodeInline: CCF | Decompresses Group 3 or Group 4 fax encoding (ITU-T T.4 and T.6). Common in scanned black-and-white pages.Lossless · 1-bit images only · Parameters1.4 §3.3.5 · 1.7 §7.4.6 | |
JBIG2Decode | Decompresses JBIG2. The encoder stores each distinct shape, such as a letter, once and refers back to it, so scanned text compresses much better than with fax encoding. Shapes several images share can go in a separate globals stream.Lossy or lossless · 1-bit images only · image XObjects only · Parameters1.4 §3.3.6 · 1.7 §7.4.7 | |
DCTDecodeInline: DCT | Decompresses JPEG: baseline, and progressive from PDF 1.3. The JPEG markers carry the size and number of components, so a JPEG file can usually be copied into the stream unchanged.Lossy · images with 8-bit components · Parameters1.4 §3.3.7 · 1.7 §7.4.8 | |
JPXDecode | Decompresses JPEG 2000. The data is a complete JPX file that describes the image itself, including its size, color space and opacity, so the image dictionary’s /ColorSpace becomes optional. Components can have 1 to 38 bits each.Lossy or lossless · image XObjects only · No parameters1.7 §7.4.9 | |
Crypt | Decrypts the stream with a crypt filter chosen by name, instead of the document’s default one for streams. It must be the first filter in the array.Decryption, not compression · any data · Parameters1.7 §7.4.10 |
In inline images
An inline image puts its data straight into a content stream, between ID and EI. Between BI and ID, /F stands for /Filter, /DP for /DecodeParms, and the filter names can be abbreviated:AHx, A85, LZW, Fl, RL, CCF andDCT. The abbreviations are only for inline images. The PDF 1.4 reference notes that Acrobat accepts them in any stream, but a writer shouldn’t count on that.
JBIG2Decode and JPXDecode can’t be used in inline images at all, and from PDF 2.0 neither can Crypt
Decode parameters
Six of the filters take parameters, in a dictionary given by /DecodeParms. Every parameter is optional, and a stream whose filters all use their defaults can leave /DecodeParms out.ASCIIHexDecode, ASCII85Decode, RunLengthDecode andJPXDecode take none: JPEG 2000 data describes itself.
LZWDecode and FlateDecode
Both filters can reverse a predictor. Before compressing image-like data, the encoder can replace each value with its difference from a neighbor, which turns smooth areas into runs of small numbers that compress well. Apart from EarlyChange, the parameters only describe that step, and they must match what the encoder did.
| Key | Default | What it means |
|---|---|---|
/Predictorinteger | 1 | The predictor the encoder used: 1 for none, 2 for TIFF, 10 to 15 for PNG. See Predictors below. |
/Colorsinteger | 1 | Color components per sample: 1 to 4 before PDF 1.3, any number from 1 since. Used only when Predictor is greater than 1. |
/BitsPerComponentinteger | 8 | Bits per color component: 1, 2, 4 or 8, and 16 from PDF 1.5. Used only when Predictor is greater than 1. |
/Columnsinteger | 1 | Samples per row, normally the image’s width. Used only when Predictor is greater than 1. The default is rarely right, so a stream with a predictor nearly always sets it. |
/EarlyChangeinteger | 1 | LZWDecode only. When the code length grows. With 1, each longer code length starts one code early, as some widely used LZW code did; with 0, as late as possible. |
Predictors
The value of /Predictor says which predictor the encoder used:
| Value | Predictor | Each value is predicted from |
|---|---|---|
1 | None | Nothing: the data was compressed as it is. The default. |
2 | TIFF Predictor 2 | The same color component of the sample to the left. |
10 | PNG None | Nothing, but each row still has a tag byte. |
11 | PNG Sub | The byte to the left. |
12 | PNG Up | The byte above. |
13 | PNG Average | The average of the bytes to the left and above. |
14 | PNG Paeth | The byte to the left, above or above-left, whichever is closest to left + above − above-left. |
15 | PNG optimum | Any of the PNG predictors, chosen by the encoder row by row. |
The PNG predictors work on bytes: “left” is the matching byte of the sample to the left and “above” the matching byte in the row above, whatever the number of components and their bit depth. Each row of the decompressed data starts with a tag byte naming the predictor used for that row (0 None, 1 Sub, 2 Up, 3 Average, 4 Paeth, as in PNG), so a reader only needs to know that some PNG predictor is in use: any value from 10 to 15 decodes the same data. TIFF Predictor 2 has no tag byte and predicts whole color components instead of bytes. Either way, each row is padded to a whole number of bytes, and anything outside the image counts as 0.
One common place to meet a predictor is a cross-reference stream (PDF 1.5). With /W [1 2 1] each entry is a row of four bytes, and the Up predictor turns the bytes that hardly change from one entry to the next into zeros, which Flate compresses well:
2 0 obj << /Type /XRef /Size 3 /W [1 2 1] /Root 1 0 R /Filter /FlateDecode /DecodeParms << /Predictor 12 /Columns 4 >> /Length … >> stream …Flate-compressed rows… endstream endobj
| After Flate | After the predictor | Entry |
|---|---|---|
02 00 00 00 FF | 00 00 00 FF | Object 0, free |
02 01 00 0F 01 | 01 00 0F 00 | Object 1, at byte 15 |
02 00 00 40 00 | 01 00 4F 00 | Object 2, at byte 79 |
Each row starts with the tag 02 (Up). The reader drops the tag and adds each remaining byte to the byte above it, modulo 256, starting from a row of zeros: in the second row, 01 + FF wraps around to 00.
CCITTFaxDecode
The parameters describe how the fax data was encoded, and except where noted they must match the encoder’s choices. The ones that matter most are K (which group), Columns and Rows (the size) and BlackIs1. With no parameters at all, the filter expects Group 3 one-dimensional data, 1728 pixels wide, the width of a standard fax line.
| Key | Default | What it means |
|---|---|---|
/Kinteger | 0 | The encoding: negative for Group 4 (two-dimensional), 0 for Group 3 one-dimensional, positive for Group 3 two-dimensional, where each one-dimensional line can be followed by up to K − 1 two-dimensional lines. The decoder only looks at the sign. |
/EndOfLineboolean | false | Whether end-of-line bit patterns must be present. They are accepted either way. |
/EncodedByteAlignboolean | false | Whether each encoded line is padded with 0 bits so it starts on a byte boundary. Fax machines never do this, but some software does. |
/Columnsinteger | 1728 | The image’s width in pixels. Decoded rows are padded to a whole number of bytes. |
/Rowsinteger | 0 | The image’s height in scan lines. 0 means it isn’t known in advance: the data ends with an end-of-block pattern, or just runs out. |
/EndOfBlockboolean | true | Whether the data ends with an end-of-block pattern, which then wins over Rows. If false, decoding stops after Rows lines or when the data runs out. |
/BlackIs1boolean | false | Whether 1 bits are black. The default follows the usual PDF convention for 1-bit images, where 0 is black. |
/DamagedRowsBeforeErrorinteger | 0 | How many damaged rows to put up with before failing, when EndOfLine is true and K isn’t negative. A damaged row is replaced by the row above it, or by white if that row was damaged too. |
JBIG2Decode
| Key | Default | What it means |
|---|---|---|
/JBIG2Globalsstream | none | A stream holding the bit stream’s global segments (page 0), such as a symbol dictionary shared by several images. If there are global segments, they go here even when only one image uses them. |
Each image XObject holds one JBIG2 page in the embedded organization: no file header, end-of-page or end-of-file segments, and its segments renumbered as page 1. Several images can point at the same globals stream:
<< /Type /XObject /Subtype /Image /Width 2480 /Height 3508 /ColorSpace /DeviceGray /BitsPerComponent 1 /Filter /JBIG2Decode /DecodeParms << /JBIG2Globals 6 0 R >> /Length … >>
DCTDecode
Everything else the decoder needs, from the image size to the quantization tables, is in the JPEG data itself.
| Key | Default | What it means |
|---|---|---|
/ColorTransforminteger | 1 with three components, else 0 | Whether the decoded values are converted from YCbCr to RGB (three components) or from YCbCrK to CMYK (four): 0 no, 1 yes. Ignored for one or two components. If the JPEG data has Adobe’s APP14 marker, its value wins over this entry. The specs before PDF 2.0 call YCbCr “YUV”. |
Crypt
| Key | Default | What it means |
|---|---|---|
/Typename | none | If present, /CryptFilterDecodeParms. |
/Namename | /Identity | The crypt filter that decrypts this stream: a key in the /CF dictionary of the document’s encryption dictionary, or /Identity, which passes the data through unchanged. |
In an encrypted file, every stream is decrypted with the encryption dictionary’s default crypt filter for streams (/StmF), except cross-reference streams and streams with a Crypt filter of their own. So /Identity leaves one stream, such as the XMP metadata, readable in an otherwise encrypted file. Crypt filters need /V 4 in the encryption dictionary (PDF 1.5), or /V 5 in PDF 2.0. A security handler can add entries of its own to the parameter dictionary.
<< /Type /Metadata /Subtype /XML /Length … /Filter /Crypt /DecodeParms << /Name /Identity >> >>
When the stream is also compressed, Crypt still comes first, because the data was compressed before it was encrypted: /Filter [/Crypt /FlateDecode].
Each crypt filter dictionary in /CF names its method, such as /V2 (RC4) and /AESV2 (AES-128, PDF 1.6) /AESV3 (AES-256)
What PDF 2.0 changed
ISO 32000-2 keeps all ten filters, with the same parameters and defaults, and deprecates none of them. The changes are restrictions and clarifications:
- Inline images can’t use
Crypteither, which joinsJBIG2DecodeandJPXDecode, and must give the length of their data in/L(or/Length). - Filter arrays shouldn’t list the same filter twice, and the text now says outright that a
/DecodeParmsarray follows the order of/Filter. JBIG2Decodefollows the 2019 edition of the JBIG2 standard, minus its color palette coding, so the data stays 1-bit. The spec now warns that lossy symbol matching can turn one character into another.DCTDecodeallows one, three or four components, no longer two.ColorTransformtalks of YCbCr instead of YUV and names Adobe’s APP14 marker.JPXDecodeignores chroma-key transparency in the JPEG 2000 data, and JPX layering, composition and animation aren’t supported.Cryptworks as before, but of the methods a crypt filter can use, RC4 and AES-128 are deprecated and AES-256 is new, with encryption dictionary/V 5. See Crypt.
Checked against §3.2.7 and §3.3 of the Adobe PDF Reference, third edition (PDF 1.4), with Tables 3.4, 3.5, 3.7–3.11 and 4.40 and implementation note 8 in Appendix H; §7.3.8, §7.4 and §7.6.5 of ISO 32000-1:2008 (PDF 1.7), with Tables 5, 6, 8–14, 20, 25, 26 and 94; and §7.3.8, §7.4, §7.6.6 and §8.9.7 of ISO 32000-2:2020 (PDF 2.0).