PDF to JPG: How to Pick the Right Resolution (DPI Guide + 3 Ways)

There are more reasons to turn PDF pages into JPG images than you might think: pasting bid documents into a slide deck, previewing files in a chat app, embedding pages in a website, and every form that insists on "image formats only". This post covers the one parameter that actually matters (sharpness) and the three routes you can take.

Sharpness: the one parameter worth understanding

A PDF lives in vector coordinates, so converting it to an image is fundamentally rasterization — the page gets rendered into a grid of pixels at a chosen scale. That scale, usually expressed in DPI, is what determines output sharpness:

Three rules of thumb:

1. 150 DPI is plenty for on-screen viewing — don't reflexively jump to 300. Doubling the DPI quadruples the pixel count, and the file size grows roughly fourfold with it.
2. Match the DPI to where the image ends up: 150 for slide-deck figures, 200+ for printing, 300 for the press. When in doubt, go with 150.
3. Auto-downscaling oversized pages is a necessary safeguard: rendering an A0 drawing at 300 DPI blows past the hard canvas-size limit in browsers, and silently producing a blank white image is worse than an honest error.

Three approaches compared

• pdftoppm is the canonical command-line answer: pdftoppm -jpeg -r 150 input.pdf out converts every page in one command, with -r controlling the DPI. For scripted batches it's irreplaceable.
• Watch out for server-side online sites: the conversion uploads your entire PDF — keep contracts and medical records away from them.
• In-browser local conversion (e.g. ToolVault's PDF to JPG) renders on your own device, keeps working after you go offline, and you can confirm zero uploads in the DevTools Network panel.

JPG or PNG?

• JPG: for photos, scans, and similar content — small files that suit the vast majority of use cases.
• PNG: sharper when the page contains text screenshots, UI captures, or line art; but a text-heavy PDF converted to PNG can come out 5–10× larger than the JPG equivalent.

The simple rule: JPG for images people look at; PNG for text-heavy graphics someone will zoom into.

Common pitfalls

1. Scans come out blurry: the scan itself is low-DPI (200 is common), and re-rendering at a higher DPI won't sharpen it — rasterization can't conjure detail out of nothing. The original quality is the ceiling.
2. Pages come back out of order: after a batch conversion, files sort by name, so the page suffix needs zero-padding to sort correctly (page 3 = -03.jpg); unpadded, -3.jpg lands after -10.jpg.
3. Transparent backgrounds turn black: a few PDFs carry transparent layers, and JPG has no alpha support. A good converter composites a white background instead of emitting black blocks.
4. Encrypted PDFs: password-protected files need to be decrypted first (assuming you know the password) before converting.

Implementation notes

Engineering notes on browser-side rasterization: the pdf.js worker must match the main library's version exactly (mixing versions fails silently at runtime); the render scale needs a protective clamp against hard canvas-size limits (iOS Safari caps canvas dimensions well below desktop Chrome); and memory reclamation matters when converting dozens of pages — reset each canvas's dimensions to zero once its page is rendered, or a long-running job will crash the tab on mobile. None of these details are visible to users, yet they draw the line between "50 pages convert smoothly" and "the page freezes halfway".

Bottom line

For occasional conversions, use an in-browser local tool (ToolVault PDF to JPG) at 150 DPI + JPG; for scripted batches, use pdftoppm; for sensitive documents, always steer clear of online sites that require an upload.