What DPI Should You Use When Converting PDF Pages to Images?

Updated on February 23, 2026

Every week I get some version of this question: "I converted my PDF to a JPG and the text looks blurry — what went wrong?" Nine times out of ten, the answer is DPI. It's one of those settings that tools either hide behind a default or expose without explaining what it actually means in practice. So let's fix that with a proper Q&A breakdown, matched to the three contexts where this comes up most: print, web, and archival storage.

First — what even is DPI in this context?

DPI stands for dots per inch. When you're converting a PDF page to a raster image (PNG, JPEG, TIFF, etc.), the renderer needs to decide how many pixels to map to each physical inch of the page. A standard letter-size PDF page is 8.5 × 11 inches. At 72 DPI, that becomes a 612 × 792 pixel image. At 300 DPI, the same page becomes 2550 × 3300 pixels.

PDF documents themselves are vector-based at their core — fonts and shapes are stored as mathematical descriptions, not pixels. DPI only becomes relevant the moment you "rasterize" that page into an image. So the DPI you pick is essentially your promise about how detailed the final image will be.

What DPI should I use for web display?

For the web, 96 DPI to 150 DPI is almost always enough — and often 96 is plenty. Here's why: screens render in pixels, not physical inches. A browser doesn't care that your image was rendered at 300 DPI; it just sees pixel dimensions. If you upload a 2550-pixel-wide image to display in a 900px-wide column, the browser scales it down anyway, and you've wasted bandwidth and storage for nothing.

The practical question for web use is really: "what pixel width do I need?" Work backwards from there. If your content area is 1200px wide and you want crisp rendering on retina displays (2× pixel density), aim for a 2400px-wide output image. For a standard letter PDF, that works out to roughly 150 DPI. For smaller thumbnails — say, a preview image in a document grid — 96 DPI or even 72 DPI produces perfectly clean results.

One thing that trips people up: converting a scanned PDF at low DPI for web display is fine for the display quality, but it's a separate question from whether the text is extractable. If you need OCR downstream, the resolution for recognition is different from display resolution (more on that in a moment).

What about print? I need to physically print these images.

Print is where DPI genuinely matters in the traditional sense, because physical printers do operate in dots per inch. The industry standard for offset printing and laser printing is 300 DPI. This is not arbitrary — it's the threshold at which the human eye, at normal reading distance, can no longer distinguish individual dots. Text looks sharp, photos look photographic, and thin lines hold their crispness.

For inkjet printing at home or in a photo lab, 300 DPI remains the sweet spot. Going above 300 (say, 600 DPI) produces virtually no visible improvement for most content, but doubles your file size. The exception is very fine technical drawings or engineering diagrams with hairline details — those sometimes benefit from 400–600 DPI. For large-format prints (banners, posters) viewed from a distance, you can often drop to 150 DPI since the viewing distance compensates for lower detail.

A practical rule: if someone is handing you a PDF and asking you to prepare it for a commercial print shop, export at 300 DPI in TIFF format with no compression. Don't use JPEG for print work — JPEG's lossy compression introduces artifacts that show up at print scale even when invisible on screen.

I'm archiving documents. What DPI is appropriate for long-term storage?

Archival is where recommendations tend to be the most conservative — and for good reason. You're essentially making a bet about what future uses might require, without knowing what those are. The general guidance from institutions like the Library of Congress and various national archives:

  • Bitonal (black-and-white) documents: 400–600 DPI. This is higher than print because bitonal images at lower DPI can lose thin strokes and fine letterforms that a physical document actually contains.
  • Grayscale documents: 300–400 DPI.
  • Color documents or photographs embedded in PDFs: 400 DPI minimum, often 600 DPI for original artwork or rare materials.

For format, archival almost universally means uncompressed TIFF or losslessly compressed TIFF (LZW or ZIP). Never JPEG for archival. The argument is simple: JPEG degrades slightly every time it's re-encoded, and over decades of format migration you don't want generational loss baked into your master files.

If you're working with text-heavy PDFs that were natively digital (not scanned), 300 DPI TIFF is usually sufficient for archival since the source document was never a physical artifact — you're not trying to faithfully capture a physical object, just preserve the content.

What DPI do I need for OCR to work well?

Text extraction via OCR (optical character recognition) has its own DPI requirements that don't neatly map to print or web guidance. Most OCR engines — Tesseract being the most widely used open-source one — perform best in the 200–400 DPI range for printed text. Below 150 DPI, accuracy degrades noticeably, especially for small fonts and numerals. Above 400 DPI, accuracy typically plateaus or even drops slightly because very high resolution can confuse the engine with noise and texture it wasn't trained to handle at that scale.

The sweet spot most practitioners land on is 300 DPI for OCR preprocessing. It's high enough that character features (serifs, crossbars, dot positioning) are clearly rendered, but not so high that you're creating massive files that slow down processing pipelines.

One nuance: if the source PDF is a scanned document that was already scanned at low quality (a bad photocopy, a fax-to-PDF workflow from 2003), no amount of high-DPI re-rendering will recover text that isn't there. The DPI setting in your PDF-to-image tool scales the vector rendering of what the PDF contains — it cannot invent detail from a blurry embedded bitmap.

What's the actual DPI setting in common tools?

It varies more than it should. Here's a quick reference for how different tools handle this:

Adobe Acrobat: When you export to image, it exposes DPI directly in the export dialog. Default is typically 150 for JPEG and 300 for PNG/TIFF. Change it — the default for JPEG is too low for anything print-bound.

ImageMagick (command line): Use the -density flag before the input file, not after. This catches a lot of people: convert -density 300 input.pdf output.png is correct. Putting -density after the input means it applies to the output, which does a different (wrong) thing — it resamples rather than renders at the target resolution.

Ghostscript: The -r flag sets resolution. gs -dNOPAUSE -sDEVICE=tiff24nc -r300 -sOutputFile=page_%d.tif input.pdf -c quit renders at 300 DPI. Ghostscript is often faster than ImageMagick for batch jobs because ImageMagick calls Ghostscript internally anyway — you're just cutting out the middleman.

Python (pdf2image / pypdfium2): pdf2image exposes a dpi parameter directly: convert_from_path('input.pdf', dpi=300). pypdfium2 uses a scale parameter instead — scale 1.0 corresponds to 72 DPI (PDF's native unit), so for 300 DPI you pass scale=300/72 or roughly 4.167.

Any quick cheat sheet to summarize this?

Sure — here's the short version:

  • Web thumbnails / preview images: 72–96 DPI
  • Web display (standard retina screens): 144–150 DPI
  • Print (home, office, commercial): 300 DPI
  • Fine print / detailed technical drawings: 400–600 DPI
  • OCR text extraction: 300 DPI
  • Archival (color/grayscale): 300–400 DPI, TIFF
  • Archival (bitonal/scanned originals): 400–600 DPI, TIFF

One last thing worth saying plainly: don't cargo-cult 300 DPI everywhere. I've seen production workflows churning out 300 DPI JPEGs for email newsletter headers, generating 800KB images when a 40KB image at 96 DPI would have been visually identical. Match your resolution to your actual output medium, and you'll save storage, bandwidth, and processing time without sacrificing a single visible pixel.