A 2480x3508 scan can be 400 or 600 dpi in a PDF, depending on its size on the page

Scan an A4 page at 300 dpi and you get an image of roughly 2480×3508 pixels. It is easy to assume that the 300 travels with the image, so a PDF built from it holds a 300 dpi image. That is only half true. The numbers below were measured on 2026-11-06 on an Apple M4 Mac, using self-made test files: a one-page A4 test image at 2480×3508 with some scanner-style noise and blur, and a two-page PDF with a photo in it (the photo is derived from a CC0 image on Wikimedia Commons). All numbers are single runs on one machine.

Effective DPI comes from the box on the page

Inside a PDF, an image object records its width and height in pixels. My reading of the PDF spec is that there is no field that says "300 dpi"; that part comes from the spec, not from this test. What the page has instead is a drawing instruction that stretches the image into a box, and that box is measured in points, where 72 points make one inch. The resolution you actually get on paper or on screen comes from putting those two together, and people call it effective DPI: pixels divided by the box size in inches, where inches are points divided by 72. Width and height are worked out separately. A full A4 page is 8.27 by 11.69 inches, so a 2481×3508 page image that fills it lands at 300 by 300, which is what the scanner promised. A photo is a different story. In my two-page sample, a 4032×3024 photo sits 12 cm wide on the page, which is 4.72 by 3.54 inches, and that works out to 853 dpi. Nothing in the photo file says 853. It only became 853 when it was placed at that size.

Four placements gave 400 to 600 dpi

To see it without anything else changing, one 2480×3508 image was placed into four PDFs at four sizes, all smaller than the full page, without resampling it. The pixel count is identical in every file. The snippet below is only an illustration: it redoes the division on the rounded box sizes, while the dpi values themselves were read from the four PDFs:

px_w, px_h = 2480, 3508
for w_in, h_in in [(6.20, 8.77), (5.64, 7.97), (5.39, 7.63), (4.13, 5.85)]:
    print(f"{w_in:.2f} x {h_in:.2f} in -> {px_w / w_in:.0f} x {px_h / h_in:.0f} dpi")

6.20 x 8.77 in -> 400 x 400 dpi
5.64 x 7.97 in -> 440 x 440 dpi
5.39 x 7.63 in -> 460 x 460 dpi
4.13 x 5.85 in -> 600 x 600 dpi

Same image, four answers, and the only thing that moved was the box. You don't have to write any code to read this from a file, though. On my two samples, the x-ppi and y-ppi columns of pdfimages -list gave the same 853 and 300 that I got from the box sizes.

Why care? Because text inside a scan is just pixels too, and its height in pixels is the point size times effective DPI divided by 72. A 6 pt line at 100 dpi is about 8 pixels tall and at 72 dpi about 6. With the full-page test image downsampled to 150 dpi, 6 to 12 pt lines in English and Chinese were all still recognized at 99% or better by macOS text recognition, so the pixel budget only starts to bite below that.

Ghostscript printer kept the 440 dpi copy

Compressors work on effective DPI, which is where the four placements became interesting. Ghostscript 10.07.1's /printer preset targets 300 dpi for color images, so you might expect all four copies to come out at 300. They didn't. The 400 and 440 copies were left exactly as they were, and only the 460 and 600 copies were brought down to 300. Ghostscript leaves an image alone until it is about 1.5 times the target, so for /printer the line falls between the 440 and 460 copies. The /ebook preset, which targets 150, did reduce all four, landing at 150, 147, 153 and 150. A full-page 300 dpi scan-style PDF went through /printer with its images untouched, and the output was 0.08% larger than the input.

ImgIng https://imging.ai/ , a PDF compressor that runs in a desktop browser, also names its presets by target DPI: screen 72, ebook 150 and print 300, and an image that is already below the preset is not resampled. Once I read those labels as effective DPI they made sense. The 853 dpi photo has a lot to lose under ebook 150, while a full-page 300 dpi scan has nothing above the print 300 line. I haven't checked whether ImgIng uses a threshold like Ghostscript's 1.5, so I can't say what it does with a 440 dpi image under print 300.

Two cases had no test files, and I'm honestly not sure about them. If an image is stretched unevenly, x and y effective DPI differ, which is presumably why pdfimages reports two columns. And if one image object is drawn on two pages at two sizes, it has two effective DPIs, and I don't know which one a given compressor goes by. For ordinary files, the x-ppi column already shows how far each image sits above a 150 or 300 preset, before you compress anything.