📐 PDF Image Resolution Picker

Why DPI Is the Single Most Important Setting When Converting PDF to Images

Most people treat PDF-to-image conversion as a two-step affair: pick a tool, click convert, done. They end up with images that are either blurry when printed or so large they break email attachment limits. The culprit is almost always DPI — dots per inch — and the fact that most tools quietly decide this number for you, usually badly.

Understanding DPI in the context of PDFs requires a small mental model shift. PDFs themselves are resolution-independent. A PDF page is defined in points (1 point = 1/72 of an inch), and the shapes, text, and vector graphics inside it are mathematical descriptions, not pixel grids. When you tell a renderer "give me this page as an image," the first question it has to answer is: how many pixels should each inch of the page produce? That answer is your DPI setting.

How the PDF Coordinate System Maps to Pixels

The PDF specification uses a default user space where one unit equals 1/72 of an inch. This is not arbitrary — it matches the traditional typographic point. An A4 page (210 × 297 mm) in PDF units is 595 × 842 points. When you render at 72 DPI, each point becomes exactly one pixel, so the output is 595 × 842 pixels. Double the DPI to 144, and each point becomes two pixels, giving you 1190 × 1684 pixels with four times the pixel count.

The scale factor for rendering is simply: scale = desired_DPI / 72. At 300 DPI, scale = 4.166, meaning every inch of the original PDF becomes 300 pixels in the output image. This is how PDF.js calculates its viewport internally — and it is why choosing 300 DPI for an A4 document produces a 2480 × 3508 pixel image, the exact pixel count required for true 300 DPI print on A4.

The DPI Sweet Spots — and What Lives at Each

72 DPI is the historical "screen resolution" derived from early Macintosh displays. Modern screens have long surpassed 72 PPI (pixels per inch), but 72 DPI output is still useful for rough thumbnails, draft previews embedded in CMS systems, or situations where a human just needs to read the page visually at 100% zoom in a browser. File sizes are minimal — often under 100 KB per page for a text-heavy document.

96 DPI is the Windows display baseline and gives slightly sharper results on modern screens that assume a 96 DPI environment. If you are generating images that will render at exactly their pixel size in a web app (for example, a document preview panel), 96 DPI often looks sharper than 72 without the jump in file size.

150 DPI is underrated. Many office printers handle 150 DPI output well, and the file sizes are typically 3-4× smaller than 300 DPI equivalents. If your use case is "send to a home inkjet to read as a draft," 150 DPI is genuinely sufficient and produces much faster email delivery.

300 DPI is the professional print standard. Offset printing presses, digital laser printers in office environments, and all standard print-ready workflows specify 300 DPI as the minimum. At 300 DPI, text edges are crisp even under magnification, thin lines in charts do not blur, and the output is indistinguishable from the source at arm's length. This is the safest default for any document destined for paper.

600 DPI is territory for offset lithography, fine-art reproduction, and engineering drawings where dimension annotations must remain pixel-perfect at print. A 600 DPI image of an A4 page is 4960 × 7016 pixels and will clock in at multiple megabytes per page. For anything short of professional presswork, it is overkill.

Raster vs. Vector Content Inside a PDF — Why It Changes Everything

Here is the nuance most DPI guides skip: the benefits of high DPI are not uniform across all content types in a PDF. Text and vector graphics (charts, diagrams drawn with paths) are resolution-independent inside the PDF — the rendering engine redraws them at whatever DPI you choose, so they are always sharp. Raster images that were embedded in the PDF (photos, scanned pages) have a fixed internal resolution. If a photo was inserted at 150 DPI, rendering the PDF at 300 DPI will not magically recover details that do not exist in the source. It will simply upscale the embedded bitmap, which can actually introduce softness from interpolation.

The practical implication: for PDFs that are entirely vector (design files, generated reports, typography-heavy documents), higher DPI genuinely improves output sharpness. For scanned PDFs, increasing DPI beyond the original scan resolution adds no information — you are better off re-scanning at higher resolution if sharpness is the goal.

File Size vs. Quality: The Math Behind the Trade-off

Doubling DPI quadruples pixel count, which approximately quadruples uncompressed file size. PNG compression reclaims much of this for solid-color regions (like white backgrounds), but photograph-heavy PDFs see near-linear size growth. JPEG compression at quality 90 dramatically cuts sizes at 300 DPI, often by 70-80% versus lossless PNG, but introduces compression artifacts around sharp edges like text. WebP sits between the two — better compression than JPEG at equivalent visual quality, with browser support now exceeding 95% of global traffic.

A quick mental benchmark for a single A4 page of mixed text and graphics: 72 DPI PNG ≈ 80–150 KB, 150 DPI PNG ≈ 400–700 KB, 300 DPI PNG ≈ 1.5–3 MB, 300 DPI JPEG (q90) ≈ 200–500 KB.

Browser-Side Conversion: What PDF.js Actually Does

The PDF Image Resolution Picker tool above uses PDF.js, Mozilla's pure-JavaScript PDF renderer, to render pages into an HTML canvas element. The canvas dimensions are set by multiplying the page's point dimensions by the DPI scale factor. Once rendered, the canvas is exported via canvas.toBlob() to the chosen format. This happens entirely in your browser — the PDF bytes never leave your machine, which matters for confidential documents like invoices, legal contracts, or medical reports.

The tradeoff is performance. At 600 DPI, a canvas for an A4 page is nearly 35 megapixels. Most modern browsers can handle this, but it will consume significant RAM and rendering time. At 300 DPI, rendering a 10-page document typically completes in under 30 seconds on a mid-range laptop. At 72 DPI, it is nearly instant.

Practical Workflows by Use Case

For creating web page previews of uploaded documents, 96–150 DPI JPEG or WebP hits the right balance — fast to generate, fast to serve, acceptable visual quality on HiDPI screens when displayed at half pixel size. For preparing print-ready images to hand to a commercial printer (who cannot accept your PDF directly), 300 DPI PNG is the safe standard. For feeding pages into an OCR pipeline, 300 DPI is the documented sweet spot for most OCR engines including Tesseract — below 200 DPI, character recognition accuracy drops measurably. For archival purposes (replacing scans), 400 DPI TIFF is the library standard, though TIFF output requires server-side tooling beyond what a browser canvas can produce natively.

Whatever your target, the key discipline is to decide your DPI before you convert, not as an afterthought. Upscaling a 72 DPI image to 300 DPI in an image editor is meaningless — you are interpolating pixels, not recovering information. The resolution decision has to be made at the rendering stage, when the PDF's mathematical descriptions are being turned into a pixel grid for the first time. That is exactly what this tool lets you control.