Photos in a PDF: What Happens to a JPG, a PNG and a HEIC

An image in a PDF is an image XObject: a grid of pixel values, a colour space that says what the values mean, and a filter that says how the grid was compressed. ISO 32000-2, the current PDF standard, defines a short list of filters, and only some of them suit photographs. DCTDecode (section 7.4.8) is baseline and progressive JPEG. JPXDecode (7.4.9) is JPEG 2000. FlateDecode (7.4.4) is the deflate compression used by ZIP and by PNG. The others are for scans: CCITTFaxDecode and JBIG2Decode handle black-and-white pages, RunLengthDecode handles simple graphics.

WebP, AVIF, HEIC and GIF are not on the list. A reader is under no obligation to understand them, and none of the common ones do. So when one of those files becomes a PDF page, its pixels have to be decoded and stored again in a format the standard does name. That is a real conversion, with the choices any conversion involves.

DCTDecode is the JPEG baseline and progressive coding from ITU-T T.81, the same data a .jpg file holds after its headers. A converter can therefore take the compressed bytes of your photo, wrap them in an image dictionary that states the width, height and colour space, and write them into the PDF without ever decompressing them. The pixels in the PDF are exactly the pixels in your file, and the PDF grows by roughly the size of the photo.

The alternative, which many converters take, is to decode the JPEG, draw it onto a canvas and save it as a new JPEG. Every such pass discards a little more detail, mostly as smearing around sharp edges and in fine texture. It also usually changes the file size in one direction or the other, which is the easiest way to tell which kind of converter you are using: if a 3 MB photo comes out as a 900 KB page, something was recompressed.

The exception is CMYK. Photoshop writes CMYK JPEGs with an Adobe marker and its channel values inverted, and a PDF that carries those bytes unchanged needs a Decode array to flip them back, or the page shows a photographic negative. Redrawing such a file once at high quality is the safer way to get the colours right.

A phone's sensor has one fixed orientation. Hold the phone upright, and the camera still records the image lying on its side, then writes a note in the file saying how to turn it. That note is the Orientation tag, number 274 (0x0112) in the Exif standard published by CIPA and JEITA. It takes a value from 1 to 8: 1 means the pixels are already upright, 6 means turn them a quarter turn clockwise, 3 means half a turn, and the values 2, 4, 5 and 7 add a mirror image, which is rare in practice.

Photo apps and browsers read the tag and show the picture upright, so you never see the problem until the photo meets a program that ignores it. A PDF is one of those. DCTDecode describes compressed pixels and nothing else, and no part of the image dictionary records an Exif orientation. A converter that copies the JPEG bytes and stops there gives you a document full of portraits lying on their sides.

The fix does not require touching the pixels. Every image in a PDF is drawn through a transformation matrix, the cm operator, that maps the image onto the page. Rotating or mirroring the image is a matter of choosing that matrix, so the JPEG keeps its original bytes and simply gets drawn turned the right way. This tool reads the Orientation tag, combines it with any rotation you add by hand, and builds the matrix from both.

A photo is a count of pixels, 4032 by 3024 for a typical 12-megapixel phone camera. It has no physical size of its own. The dpi value stored in many JPEGs is a suggestion that most cameras set to 72 regardless of anything, and most software ignores it. A PDF page, on the other hand, has a definite size, measured in points of 1/72 inch (section 8.3.2.3). A4 is 210 by 297 millimetres under ISO 216, which comes to 595.28 by 841.89 points. US Letter is 8.5 by 11 inches, or 612 by 792.

So putting a photo into a PDF means choosing how large to make it, and the choice sets the effective resolution. That photo on a landscape A4 page with small margins is limited by the page's height and comes out about 10.4 by 7.8 inches, which works out to roughly 390 pixels per inch, comfortably above the 300 that print shops ask for. The same photo on a page cut to its own shape needs some rule for converting pixels to inches. This tool uses 96 pixels to the inch, the reference pixel CSS defines, so the page comes out about 42 by 31 inches. That sounds absurd but costs nothing: the file holds the same pixels either way, viewers zoom to fit, and a printer scales the page to the paper in the tray. Pick a paper size when the PDF is going to be printed or submitted, and the image's own shape when it is going to be read on a screen.

For JPEGs copied as they are, the PDF is the sum of the photos plus a few hundred bytes per page for the page object, the image dictionary and the drawing instructions. Ten 3 MB photos make a PDF of about 30 MB. If that is too large to email, the fix is to make the photos smaller before they go in, by resizing them to something near the print size or lowering the JPEG quality. Nothing in the PDF step can shrink them without recompressing.

PNGs behave differently. The PNG format applies a filter to each row of pixels before compressing, and a good encoder tries several to find the one that compresses best. When the pixels are stored with FlateDecode in a PDF they are compressed again, often without those row filters, so a PNG that was carefully optimised can grow on the way in. A transparent PNG also becomes two images, because PDF keeps transparency in a separate greyscale soft mask referenced from the image dictionary. If a PDF built from screenshots is much bigger than expected, saving them as high-quality JPEGs first will usually cut it by more than half, at the cost of slightly soft text.