PNG transparency — what happens to alpha in a PDF
PNG's killer feature for screenshots and graphics is its alpha channel — per-pixel transparency that lets logos sit cleanly over any background. PDF supports the same concept but stores it differently: the alpha is split out into a separate "soft mask" image, which the renderer composites against the page background at display time.
How PNG stores alpha
PNG has five color types, four of which can carry transparency:
- Type 4: grayscale + alpha. Each pixel is two bytes (gray, alpha) at 8-bit depth.
- Type 6: RGB + alpha (RGBA). Four bytes per pixel at 8-bit.
- Indexed (type 3): alpha can be specified per palette entry via the
tRNSchunk. - Truecolor (type 2): a single RGB triple in
tRNScan be marked as fully transparent ("color-key transparency").
RGBA (type 6) is by far the most common in modern files — it's what every graphics tool exports.
How PDF stores alpha
PDF's Image XObject does not have a 4-channel "RGBA" mode. Instead, alpha lives in a separate Image XObject called a soft mask, referenced via the /SMask entry on the parent image:
<< /Type /XObject /Subtype /Image
/Width 1920 /Height 1080
/ColorSpace /DeviceRGB
/BitsPerComponent 8
/Filter /FlateDecode
/SMask 12 0 R %% reference to alpha mask
>>
The mask is a single-channel grayscale image of the same dimensions:
%% object 12 0
<< /Type /XObject /Subtype /Image
/Width 1920 /Height 1080
/ColorSpace /DeviceGray
/BitsPerComponent 8
/Matte [255 255 255] %% optional, for premultiplied
>>
At render time, the PDF reader paints the page, then composites the parent image over it using the mask as alpha. The result is identical to the PNG's per-pixel transparency, except for one thing: what's behind it.
The page background is white
A PDF page has no inherent background color (technically the PDF "media box" is unfilled and viewers paint white behind it). When you place a partially-transparent image on a page, the alpha blends against white. This is what users almost always want — a logo with a transparent background appears cleanly on the white page — but it is different from the original PNG's behavior.
If you opened the same PNG on a dark website, the transparent regions would show the dark website behind the logo. In a PDF, those same regions show white. Your transparent badge that looked great on the dark site looks like it has a halo when placed in a PDF.
This is not a conversion bug. PNG transparency is conditional ("show what's underneath"); PDF rendering substitutes white for "what's underneath". The conversion preserves the alpha channel exactly; the rendered appearance differs because the background differs.
Solving the halo problem
If your PNG has anti-aliased edges that were drawn assuming a specific background color (often the case with logos exported from design tools), those edges contain partially-transparent pixels with the original background color baked in. When composited against white, they show a faint halo.
Two solutions:
- Accept the halo: usually it's invisible at typical viewing distance.
- Pre-flatten the PNG against white in a graphics tool: open the PNG in any image editor (Photoshop, GIMP, even Preview on Mac), add a white background layer behind the image, and re-export as PNG. The result has no alpha; the edges are perfectly anti-aliased against white. Then convert with PNG2PDF — the resulting PDF page has no transparency at all, just clean composited pixels.
Palette transparency (the tRNS chunk)
Indexed PNGs (256 or fewer colors) can specify per-palette-entry alpha via tRNS. Most often this is used to make a single palette entry fully transparent — "this color should be transparent" in classic GIF style.
PDF doesn't have a direct equivalent of "indexed + per-entry alpha". In practice, indexed-with-tRNS PNGs end up represented in the output PDF as an RGB Image XObject plus an SMask — the same shape as a regular RGBA PNG. Some efficiency is lost (palettized data compresses better than RGB), but the alpha is correct.
Bit depth of the alpha channel
Alpha-carrying PNG types (4 and 6) support only 8 or 16 bits per channel — the PNG spec does not allow 1/2/4-bit alpha in those types. PDF's /SMask also only supports 8 or 16 bits per pixel.
16-bit alpha is rare (some scientific imaging tools produce it). In practice the output PDF settles on 8-bit alpha because viewer support for 16-bit is uneven, and 256 levels of transparency are indistinguishable from 65536 to the eye for almost every visual application.
Testing the result
Open the converted PDF in Acrobat or Preview against a non-white page background:
- If the transparent regions show as white on a colored screen background, the page background is being painted white before the SMask composites — expected behavior.
- If transparent regions show as solid color, the SMask wasn't written or the viewer ignored it — this would be a conversion bug; report it.