PDF to Image

A PDF is fundamentally a vector document: text and graphics are described mathematically, not as pixel grids. That's why PDF is great for printing (scales to any size without losing quality) and good for screen reading (fonts stay crisp at any zoom). But sometimes you need a PDF page as a flat image — for embedding in a slide deck, posting on social media, attaching to a CMS that doesn't accept PDFs, or saving a snapshot that's hard to edit. This conversion is technically called "rasterising" — turning vector instructions into a fixed pixel grid. Once a page is rasterised, the embedded text is no longer selectable and the file size depends entirely on dimensions and compression, not the original document complexity.

What actually does the rendering

This page uses pdf.js 4.10.38, Mozilla's PDF renderer — the same engine that displays PDFs inside Firefox. It is served from this domain as two files, a 353 KB main module and a 1.34 MB worker, and both are byte-identical copies of the published npm package. The page asks pdf.js for a page, asks for a viewport at scale = DPI ÷ 72 — 72 because a PDF's default user-space unit is 1/72 inch (ISO 32000-2, 8.3.2.3) — draws that viewport onto an HTML <canvas>, and then calls the canvas's own toBlob() to encode a JPG, PNG or WebP. The encoder is your browser's, not ours.

Chrome, Edge and Safari do not use pdf.js: Chromium ships PDFium, which Google derived from Foxit's engine, and Safari uses Apple's PDFKit. They are separate implementations of the same published format, which is why the same PDF can look subtly different in three viewers. Nothing about this pipeline touches a RECATOOLS server — the file is read with File.arrayBuffer() and never leaves the tab.

At 300 DPI, a single A4 PDF page renders to roughly 2480×3508 pixels — about 8.7 megapixels per page. A 50-page PDF at 300 DPI generates 435 megapixels of canvas — roughly 1.7 GB of pixel data if every page is held at once, which is why phones give up first.

DPI is the setting that decides everything else

DPI ("dots per inch") controls how detailed the rasterised image is. Desktop screens sit around 100–160 ppi; current phone screens are 320–460 ppi; print is 300–600 dpi. For most web uses (CMS embeds, social posts, slide decks), 150 DPI is plenty — the resulting image is sharp on retina screens at the document's intended display size and stays reasonable in file size. Bump to 300 DPI only if you'll print the output or need detail (small text legibility, fine-grained diagrams). Going above 300 DPI is rarely worth the file-size cost unless the document is meant to be enlarged.

JPG vs PNG vs WebP for PDF pages

JPG works for almost everything but introduces lossy compression artefacts around sharp text and lines — usually invisible at 85%+ quality. PNG preserves every pixel exactly (no artefacts) but files are several times larger; use it for documents with lots of fine text or diagrams where legibility matters. Note that PNG output here is opaque, not transparent: pdf.js fills the canvas white before it draws, so there is no alpha channel to preserve. For WebP, Google's own comparison study reports files 25–34% smaller than JPEG at equivalent SSIM — worth taking where you control the software that will open the file.

What this tool doesn't do

It doesn't OCR — if your PDF is a scan, the output is still a picture, not editable text. It doesn't preserve layers, tagging or text: rasterising flattens everything, and that is usually the point. It doesn't open encrypted PDFs — this page never prompts for a password, so a protected file fails at load and has to be decrypted first in your own PDF reader. It doesn't crop, rotate, or composite pages onto one image. For those, render the pages here and then process the images in our Image Format Converter or Watermark Maker.