PDF to Images

When PDF-to-Image Is the Right Conversion

PDFs are vector + text + image documents; images are pixel arrays. Converting PDF → images is a destructive, lossy conversion: you lose searchable text, you lose vector crispness at scales beyond your chosen DPI, and you bake one specific rendering of the page into pixels. You also gain compatibility, any tool that accepts images now accepts your PDF pages.

This is the right conversion when:

• You need to embed PDF pages in a document that doesn't import PDFs well. PowerPoint imports PDFs poorly (or not at all on some platforms). Google Docs can't insert PDF pages directly. Markdown files accept images, not PDFs. Convert to PNG/JPEG, insert images.
• You're feeding an image-only pipeline. Some OCR engines, computer vision models, or image-tagging tools accept only images.
• You want page screenshots for social media or marketing. A whitepaper's "infographic" page makes a great Twitter image at the right crop.
• You're archiving a snapshot of a specific rendering. PDFs render slightly differently across viewers (font substitution, color management). Converting to images locks in one rendering.

This is the WRONG conversion when:

• You need searchable / editable text. Use the PDF Text Extractor.
• You're "compressing" the PDF. PDF→image→PDF usually produces a LARGER, lower-quality file than the original.
• You need to preserve interactivity (links, forms, annotations). Images can't have those.

How Rendering Works

PDF.js parses the page content stream and dispatches drawing operations to a canvas (or to PDF.js's internal renderer that outputs to a canvas). The canvas is then exported as a PNG or JPEG Blob.

The canvas's pixel dimensions are determined by:

Where scale = DPI / 72 (PDF uses 72 points per inch).

So an A4 page (595 × 842 points) at 150 DPI becomes a 1239 × 1754 pixel image.

This is rendering, not extraction. Vector content (text, shapes) gets rasterized; embedded raster images get resampled (upscaled or downscaled depending on the source image's DPI vs your target DPI).

DPI Decision Tree

• Will the image be displayed at original size? 72-100 DPI is fine.
• Will it be displayed on a high-DPI (Retina) screen? Double the above: 150-200 DPI.
• Will it be printed? 300 DPI is the standard for print quality.
• Is the source PDF a scan with text that needs OCR? Match the scan's native DPI (often 200-300) or go slightly higher for OCR accuracy.
• Archival, fine detail, or you don't know? 300 DPI is a reasonable default.

Don't blindly maximize DPI: 600 DPI quadruples file size vs 300 DPI with no visible quality improvement on screen.

Format Choice

This tool produces PNG and JPEG (universal compatibility). For WEBP or TIFF, post-process with another tool.

JPEG quality (1-100) trades file size for fidelity. 85 is a sensible default, barely distinguishable from lossless for most content. 60-75 for thumbnails. 95+ for high-quality archives, but file size approaches PNG without the quality guarantee.

Page Range and Batching

For multi-page conversions, the tool renders each page sequentially and zips the results. Large documents (>50 pages at 300 DPI) can hit memory limits in browsers, each canvas takes width × height × 4 bytes. A 100-page A4 PDF at 300 DPI = 100 × (2480 × 3508 × 4) ≈ 3.5 GB of intermediate canvas memory if all pages held simultaneously.

The tool releases each canvas after exporting to Blob, so steady-state memory is bounded by one page. But peak memory during rendering+exporting can spike. For very large jobs, process in batches (pages 1-20, then 21-40, etc.) or use server-side tools.

Server-Side Alternatives

For batch jobs, very high DPI, or programmatic pipelines:

These are faster, handle larger files, and have more rendering options (anti-aliasing, color management). Use them when the in-browser approach hits limits.

Common Pitfalls

Text rendering differences. PDF.js and Adobe Acrobat use different font substitution heuristics when a font isn't embedded. Output may look slightly different. For pixel-perfect rendering, ensure the source PDF has all fonts embedded.

Color management. Browser canvas uses sRGB. PDFs with embedded ICC profiles (CMYK, Adobe RGB) get converted to sRGB during rendering. Color-sensitive workflows (print pre-press) should use Ghostscript with explicit color management.

Transparent backgrounds. PNGs have transparency support. PDF pages don't have "transparent" pixels per se, they have a background (usually white). The output PNG is opaque white background by default.

JPEG artifacts on text. JPEG's lossy compression creates "ringing" around sharp text edges. At quality 85 this is usually invisible; at quality 50 it's clearly visible. Use PNG for text-heavy pages, JPEG for photos.

Privacy

PDF.js renders pages to off-screen canvases in your browser. Each canvas is exported to a PNG/JPEG Blob in-memory. Multiple pages are zipped client-side. The output downloads directly, never uploaded. Open DevTools Network during conversion: zero outbound requests. Confidential pages (financial reports, medical scans, legal exhibits) stay in the tab.