I wanted to fix one number before building a preview pipeline for PDF manuals: the DPI. Pick too low and a preview may look soft on a dense screen, pick too high and every page costs more bytes to serve. The only thing I had to decide with was one 4-page brochure converted a handful of ways. This is a list of what that one file settled, and what it quietly left open.
The brochure is the first four pages of an eight-page Wikimedia Commons PDF from Wiki Education Foundation and others, CC BY-SA 3.0. It is 1,180,300 bytes, 504×720 pt per page, exported from InDesign, with a big title, body text, screenshots and page numbers. I ran it through ImgIng (图映) https://imging.ai/ in a desktop browser at its three DPI settings, and through three free online converters for comparison. Everything is one file, one Apple M4, one run each, and all sizes are exact bytes.
What the sample settled
The pixel formula held without surprises. Pixels equal points times DPI divided by 72, and because 504 and 720 are whole numbers, every setting came out exact: 1008×1440 at 144 DPI, 1512×2160 at 216, 2100×3000 at 300.
Bytes grow more slowly than pixels. The JPG output was 1,000,564 bytes at 144 DPI, 1,745,636 at 216 and 2,822,064 at 300. By my arithmetic that is 2.25 times the pixels from 144 to 216 for 1.74 times the bytes, then 4.34 times the pixels at 300 for 2.82 times the bytes. WebP and PNG moved in the same direction: 581,714 / 941,614 / 1,498,212 for WebP and 1,780,434 / 3,195,502 / 5,076,139 for PNG.
Transparency is easy to miss on a sample like this. The browser tool's PNG and WebP keep the page background transparent, with 83.3% of the pixels on page 2 at alpha 0 and 9.5% on page 1, while the JPG fills the same area with white. If a preview goes onto a dark card, that decides the format before DPI does.
On uploads, I watched the network requests. The three online converters each sent the PDF to their servers (Smallpdf to cloud storage, PDF24 and iLovePDF to their own hosts). Across 18 runs of the browser tool I saw only GET requests and nothing that carried the file. That is what these runs showed, nothing more.
What the sample could not settle
Rounding. My pages are whole-number points, so nobody had anything to round. An A4 page at 300 DPI is exactly 2480.32×3507.88 pixels, and the tools I checked disagree about the last pixel: pdftoppm and PyMuPDF give 2481×3508, a pdf.js script using floor gives 2480×3507, and ImgIng gives 2480×3508. A sample of 504×720 pt never shows you that.
The byte comparison between tools. The four JPG encoders were not set to the same quality. Reading the quantization tables suggests roughly 75 for Smallpdf, 85 for PDF24, 100 for iLovePDF and 90 to 95 for ImgIng depending on the DPI, which is an inference and not a vendor parameter. At 300 DPI the totals were 1,658,508 for Smallpdf, 2,231,511 for PDF24 and 2,822,064 for the JPG from the browser tool, and that spread is mostly the quality setting. Even inside that one tool the quality guess moved with the DPI, so my 2.82 times is DPI and quality changing together.
Clarity. I looked at one small block of page 2, a line of small print from a screenshot, at 300 DPI. Smallpdf, PDF24 and the browser tool were indistinguishable to my eye on that block, while iLovePDF's default output is 150 DPI, so the same block has fewer pixels to work with. That is one block, no PSNR or SSIM.
The free-tier limits. Smallpdf's support page says, as read on 2026-10-30, that free and unregistered users get "up to 2 conversions per day". I converted the same file 8 times without a login from one IP and the page never showed a limit message. I did not find out why, so I will not call the official number wrong. PDF24 says "No limits" on its tool page, and iLovePDF's pricing page says "Limited document processing" without a number.
The kinds of PDF I have no data on. No scans, no pages with transparency groups or unusual colour spaces, no timing, and no real huge page. The only huge pages were synthetic blank vector pages, where a canvas past 268,435,456 pixels in Chromium 149 returned a transparent blank without an error. Phones and tablets are out as well, since ImgIng only does image compression there, so PDF to image needs a desktop browser.
What I would still measure before fixing the DPI
Take the ugliest real file you have, not a clean brochure. Write down its page size in points, work out the three pixel sizes by hand, and decide how you round before any tool decides it for you. Then convert at 144, 216 and 300, and record bytes next to pixels per page, so that the 1.74 and 2.82 in this post get replaced by your own ratios. Look at a block of small text at the size your page will really show it, and only then pick the DPI.
Top comments (0)