PNG color types — indexed, grayscale, truecolor, and how PDF handles each
PNG defines five color types in IHDR. Each one maps onto a different PDF color space and has different file-size implications. Picking the right type before saving a PNG can shrink the file by 50–80%; PDF embedding inherits whatever choice the original made.
Grayscale (type 0)
One channel per pixel: brightness only. Bit depths 1, 2, 4, 8, or 16.
- 1-bit grayscale: pure black/white. 1 bit per pixel = 1/8 byte. A 1920×1080 1-bit PNG is 260 KB before compression, ~30 KB after deflate.
- 8-bit grayscale: 256 levels. Standard for grayscale photos.
- 16-bit grayscale: 65536 levels. Used in medical imaging, scientific data.
PDF maps this to /ColorSpace /DeviceGray with /BitsPerComponent typically matching the source. PDF supports up to 16 bits per component in principle, but reader support for 16-bit is uneven, so most pipelines settle on 8-bit in the output.
RGB truecolor (type 2)
Three channels per pixel (red, green, blue). Bit depths 8 or 16. The standard for photos and any image where every pixel can be a unique color.
An 8-bit RGB PNG is 24 bits per pixel before compression. Deflate compresses this well for synthetic images (large flat regions) and badly for photos (high entropy). A 1920×1080 RGB photo from a phone camera is typically ~5 MB as PNG vs ~500 KB as JPEG — PNG is lossless, JPEG is lossy.
PDF maps to /DeviceRGB with 8 bits per component in practice (PDF accepts 16, but reader support is uneven and the output usually settles on 8).
Indexed (type 3) — the underrated one
Each pixel is an index (1, 2, 4, or 8 bits) into a palette of up to 256 RGB triples stored in the PLTE chunk. For images with limited color counts — screenshots, icons, simple diagrams, anything from a UI toolkit — this is dramatically smaller than truecolor.
A 1920×1080 PNG of a typical desktop screenshot:
- As truecolor (type 2): ~800 KB after deflate.
- As indexed-8bpp (type 3): ~200 KB. Same image, 1/4 the size.
The reason: deflate compresses the indexed pixel stream more aggressively because each pixel is one byte instead of three, and consecutive pixels in flat color regions become long runs of identical bytes.
PDF supports indexed color directly: /ColorSpace [/Indexed /DeviceRGB max_index palette_data]. The indexed structure typically carries through to the output PDF, so the size benefit follows.
Grayscale + alpha (type 4)
Two channels per pixel: gray and alpha. Used for grayscale logos with soft edges, anti-aliased grayscale text exported as raster.
PDF's data model represents this with an Image XObject in /DeviceGray plus a separate /SMask grayscale stream (single-channel, used as alpha values 0–255). The transparency carries through to the output PDF.
RGB + alpha (type 6) — RGBA
Four channels: red, green, blue, alpha. The most common color type for modern PNGs from design tools. Logos, UI mockups, anything with transparent regions.
The PDF data model splits this into an RGB Image XObject in /DeviceRGB plus an associated /SMask grayscale alpha. The split costs some compression efficiency (RGB and alpha each deflate slightly worse separately than together) but is what PDF requires for soft transparency.
Palette with alpha — the tRNS chunk
Indexed PNGs can carry per-entry alpha via the tRNS chunk: an array of alpha values, one per palette entry. The combination "indexed + tRNS" is conceptually a 4-channel image but stored as 1 byte per pixel + 256-entry alpha lookup.
PDF doesn't have a direct equivalent of "indexed + per-entry alpha". In practice, indexed-with-tRNS PNGs end up represented in the PDF as RGBA — functionally identical, but losing the size advantage of palette compression. For most use cases (a logo with a few transparent palette entries), the size penalty is modest.
Bit depths and PDF's BitsPerComponent
PNG's bit depth is per-channel: a 4-bit grayscale image stores 16 levels of gray; a 4-bit indexed image addresses 16 palette entries.
PDF's BitsPerComponent is the same concept. Valid values are 1, 2, 4, 8, and 16. In practice, bit depths up to 8 carry through to the output cleanly; 16-bit usually ends up at 8 because of inconsistent reader support across PDF viewers.
1-bit PNGs (line art, fax-style scans) embed as 1-bit and stay tiny. 4-bit indexed icons stay at 4-bit and embed efficiently.
When the source PNG uses the wrong type
A common case: someone exports a screenshot as truecolor PNG when an indexed PNG would have been 1/4 the size. The PDF inherits this — embedding doesn't optimize the source.
If you want smaller output, run a PNG optimizer first:
Examples of useful pre-processing passes:
- Lossless re-encode: tries multiple filter and zlib strategies, drops non-essential metadata. Typical savings 5–25%.
- Lossy palette quantization: re-quantizes truecolor images down to a 256-entry palette. Typical savings 50–80% with very mild visual loss for screenshots and synthetic content.
Then upload the optimized version. The PDF size benefit follows the PNG size benefit.