I ran the same 4-page PDF through four PDF-to-image converters. At their defaults PDF24, iLovePDF and Smallpdf returned 1008×1440, 1050×1500 and 2100×3000 pixels, and ImgIng gave 1008×1440, 1512×2160 or 2100×3000 depending on the preset. None of the results said what DPI it had used. The word "point" is easy to leave vague, so I worked the DPI backwards from the pixel counts, and it came down to one line of arithmetic.
A PDF page has points, not pixels
The page size inside a PDF is written in points, and one point is 1/72 of an inch. My sample page is 504 × 720 points, which is exactly 7 × 10 inches. There is no pixel grid until something renders the page, and DPI is the number you hand to the renderer to say how many pixels it should spend on each inch. So the formula is pixels = points × DPI ÷ 72, and turning it around gives DPI = pixels × 72 ÷ points.
Working the DPI out of each result
I did the width first and then checked the height as a sanity test. 1008 × 72 ÷ 504 is 144, and the height agrees: 1440 × 72 ÷ 720 is also 144. The other results fall out the same way.
| Result (this 4-page sample) | Width | DPI worked out |
|---|---|---|
| PDF24, default | 1008 | 144 |
| ImgIng, middle preset | 1512 | 216 |
| iLovePDF, default | 1050 | 150 |
| Smallpdf, no DPI option in the page | 2100 | 300 |
Two of these I could check against something else. The JPG files from iLovePDF and Smallpdf carry a DPI tag of 150 and 300, which is what the arithmetic gave me. PDF24 shows 144 as its default in the interface, and ImgIng offers 144, 216 and 300 as presets. So the formula is not just a nice story, it matches what the tools themselves say.
More pixels do not mean proportionally more bytes
Going from 144 to 300 DPI multiplies the pixel count by 4.34, since 2100 × 3000 is 4.34 times 1008 × 1440. The JPG bytes at the 144 and 300 DPI presets went from 1,000,564 to 2,822,064, which is 2.82 times. Per megapixel that is roughly 689 KB at 144 DPI and 448 KB at 300 DPI (1 KB = 1000 bytes here). My reading is that big flat areas of the page compress well once there are more pixels covering them, but I only checked one booklet, so I would not trust that as a rule.
Do not compare bytes across different tools, though. Reading the JPEG quantization tables suggests the four tools use different quality levels, so a smaller zip says nothing about which one compressed better. Compare bytes only inside one tool with one setting changed.
Where the arithmetic gets fuzzy
My sample page is a clean 504 × 720, so every result is a whole number. An A4 page is 595.276 × 841.89 points, which gives a fractional pixel size at most DPIs. At 300 DPI I saw widths of 2480 and 2481 depending on the tool, because they round differently. When you work DPI backwards from an A4 result, expect to be one pixel off and round to the nearest sensible number.
What I use when I want to pick the DPI
Smallpdf gave me no DPI choice and iLovePDF defaulted to 150. PDF24 and ImgIng both let me set the number in the page; the latter, at https://imging.ai/ in a desktop browser, offers 144, 216 or 300, and in my runs I saw no request carrying the file out. On a phone it only does image compression. All numbers above are one sample, one machine and a single run each.
Top comments (0)