We convert product-spec PDFs into images and push them into a content library. It's been running about six months with the resolution hardcoded to 300 DPI, for the extremely rigorous reason that 300 was the biggest number in the dropdown. A storage review last month made me actually measure it, and the answer wasn't the one I was arguing for — it ended up changing our validation step rather than our config.
The sample is a four-page A4 PDF with mixed text, a table and an image per page, 490 KB, output as WebP. 144 DPI gives 1192×1686 per page and 317 KB total in 2.0 seconds; 216 gives 1788×2529 and 494 KB in 3.0 seconds; 300 gives 2483×3512 and 647 KB in 6.1 seconds. I opened this as a storage argument and lost it immediately: dropping 300 → 216 on a four-page document saves 153 KB. You cannot walk into a planning meeting with 153 KB. The time column is where the argument actually lives — 3.0s versus 6.1s is nothing for one document and a great deal for a nightly batch of several hundred, and ours runs overnight, so doubling it means the business side doesn't have their data in the morning. That's the version I ended up using.
Formats, same 216 DPI, four pages: WebP 494 KB in 3.0s, AVIF 552 KB in 10.3s, PNG 1.28 MB in 1.0s, JPG 1.36 MB in 1.0s. We had AVIF on the roadmap and parked it — on this sample it's bigger than WebP and three times slower. PNG beating JPEG is the one I can't fully justify; my guess is that a page dominated by flat white makes lossless cheap while JPEG burns bitrate on text edges, but I didn't verify that and it's a guess.
The part that actually changed our pipeline came from the second sample, a single page at 800×9000pt. At 216 DPI the output is 1456×16380 and 1.10 MB. At 300 DPI it is also 1456×16380 and 1.10 MB. Identical. At 216 DPI that page should be 2400×27000, and the delivered width is 1456, which works out to 1456 / (800 / 72) = 131 — below the lowest preset. My read is that there's a hard ceiling on encoded side length and tall pages get scaled to fit under it; the aspect ratio was preserved exactly, so nothing was cropped, it's a uniform downscale.
Which means our acceptance criterion — "exported images must be at least 216 DPI" — was unenforceable and had been sitting in a doc for six months unenforced. The output file doesn't carry the number you typed. There's no metadata to assert against. So it became a computation, effectiveDpi = widthPx / (pageWidthPt / 72), with anything under threshold flagged for review. Nothing clever. The part that took some arguing was that page width has to be read out of the PDF, and our batch pipeline had no reason to parse PDF metadata before this — pulling in a parser for one validation line struck a couple of people as not worth it. We did it anyway, on the grounds that this failure mode only shows up on long pages, and long pages are exactly the ones nobody scrolls to the bottom of. Nobody was ever going to report it.
What we wrote down was four rules: pick by downstream use rather than "highest is safest" — screen display 144, archive and internal lookup 216, print or OCR 300 with the time budgeted; tall pages get their own path where you compute effective DPI and split the page rather than raise the setting, since raising it does nothing; format follows content, WebP for mixed pages, PNG when lossless is genuinely required because it isn't the expensive option here, AVIF on hold; and re-measure when the corpus changes. That last one exists because we broke it first — we took one sample's numbers as a general rule and ran on them for half a year before checking whether that sample resembled our actual documents. It didn't especially.
There's also a constraint that isn't about numbers: this pipeline runs entirely in the browser, so files never leave our network. We went through a compliance review a while back and that property is the only reason this tool was allowed in at all. Parameters were the easy part.
Measured on https://imging.ai/pdf-to-image/ . The effective-DPI formula is worth adding to your validation whichever tool you use — it's the only number that describes what you actually got.
Top comments (0)