How to use
Drop a PDF onto the tool, pick a page range (single page like `5`, range like `1-3`, or all), choose the output format (PNG for lossless, JPEG for smaller files), and set the scale — 1× matches the original page dimensions in CSS pixels (~96 DPI), 2× doubles the resolution (great for retina display previews), and 3–4× produces print-quality rasterization. Each page renders into a canvas and downloads as a separate image; multi-page outputs come as a ZIP.
Reach for this when you need a PDF page as an image — embedding a chart from a report into a presentation, sharing a single page as an Instagram post, generating preview thumbnails for a PDF library UI, or extracting a diagram from a scanned document. Rendering happens entirely in the browser via PDF.js (Mozilla's open-source PDF renderer, also bundled in Firefox); the file never reaches a server, which matters for confidential documents. Note that this is rasterization — text becomes pixels, no longer selectable or searchable.
Examples
Single-page screenshot at 2×
Input
file: contract.pdf (5 pages, A4)
range: 3
format: PNG
scale: 2
Output
contract-page-3.png (1656 × 2340 px, ~400 KB)
A4 at 1× is 595 × 842 CSS pixels (~96 DPI); 2× doubles it to 1190 × 1684, then PDF.js multiplies by the device pixel ratio for crisp Retina output (final ~1656 × 2340 on a 2× device). PNG keeps the file lossless — good for screenshots that will be reviewed, marked up, or re-cropped. For preview thumbnails in a list, JPEG at quality 0.85 cuts the file size 5–10× with no visible difference at thumbnail sizes.
All pages → ZIP for archival
Input
file: report.pdf (40 pages)
range: all
format: JPEG (quality 0.85)
scale: 1.5
Output
report-pages.zip (~5 MB, 40 JPEG files)
Bulk conversion of an entire document as JPEG ZIP — useful when archiving to systems that prefer images over PDFs (some legacy DMS, photo libraries, or media systems for indexing). Each page is named `report-page-NN.jpg` in the ZIP. At 1.5× and JPEG quality 0.85, a 40-page text-heavy PDF is roughly 5 MB; raise the scale to 3× and the ZIP can balloon past 50 MB.
High-DPI print rendering
Input
file: poster.pdf (1 page, A3)
range: 1
format: PNG
scale: 3.125 (≈ 300 DPI)
Output
poster-page-1.png (4960 × 7016 px, ~12 MB)
300 DPI is the print-quality standard for posters, brochures, and color magazines. A3 at 300 DPI is 4960 × 7016 pixels; with scale = 3.125 (96 × 3.125 ≈ 300), the output matches that target. PNG keeps the colors accurate; JPEG would introduce visible compression artifacts on solid color blocks and gradients. For 4-color print, also export the PDF with embedded ICC profiles — rasterization can lose color accuracy if the source uses CMYK and the renderer assumes sRGB.
FAQ
What scale should I pick?
Match the target use. **1× (96 DPI)** for embedding in another digital document where the viewer will not zoom in. **2× (192 DPI)** for retina screen display (matches typical phone / laptop pixel density) and most casual sharing. **3× (288 DPI)** roughly matches print quality for color publications. **4× (384 DPI)** for high-DPI print (magazines, glossy brochures). Bigger output = exponentially larger file, so do not go higher than needed. A 100-page PDF rendered at 4× can easily exceed 500 MB.
PNG or JPEG — which should I use?
**PNG** for content with text, line art, charts, or any solid color — lossless, no compression artifacts on edges of letters or sharp lines. **JPEG** for photographic content or when file size matters more than pixel accuracy — much smaller for the same visual quality on continuous-tone images, but introduces "ringing" artifacts around sharp edges (especially text). For mixed content like a magazine page with text and photos, PNG is the safer default. WebP and AVIF would compress better than both but few downstream tools accept them, so this converter sticks to PNG / JPEG.
Does the output have selectable text?
No. PDF-to-image is *rasterization* — text glyphs are drawn as pixels, no underlying character encoding survives in the output. If you need selectable / searchable text from a PDF that already has it, do not rasterize: split the PDF (PDF Split tool on this site) and keep the page in PDF form. For a scanned PDF where the source is already an image, the text was never "selectable" in the first place — you need OCR (`Tesseract`, Google Cloud Vision, AWS Textract) to extract the text, and the rasterized image is sometimes the input to that OCR step.
What about page rotation and weird page sizes?
PDF.js respects the page's `Rotate` attribute and the explicit `MediaBox` (page bounds), so a landscape page that was rotated to display vertically in the source comes out vertical in the image. Unusual sizes — A3, US Legal, custom architectural sizes — render at the same physical proportions; only the resulting pixel dimensions differ. If a page has a rotation that does not match the visible orientation in your PDF viewer, that usually means the viewer is auto-correcting; PDF.js gives you the raw rotated form.
Why is my output huge?
Three causes. **Scale too high** — 4× on A4 produces nearly 8 megapixels per page; 100 pages = 800 megapixels of raster data. Cut the scale to what you actually need. **PNG when JPEG fits** — PNG is lossless but big; switch to JPEG quality 0.85 for any photographic content. **Pages have rich vector content** — fully rasterizing a vector chart to 4× produces a much bigger file than the source PDF page. If output size matters more than fidelity, keep the source PDF and use the JPEG path; if you can stand JPEG quality 0.7, file size drops another 40% beyond 0.85.
Can it handle a PDF with forms or annotations?
Yes, but with caveats. PDF.js renders form fields with their current values, so a form filled in with "Alice" shows "Alice" in the output image. **Annotations** (highlights, sticky notes, comments) render in place by default; if you need a clean copy without annotations, flatten them first via Adobe Acrobat or a `pdf-lib` script before converting. Interactive elements (clickable buttons, radio selections) are obviously dead in the static image. For form processing pipelines, render before saving the form — the rendered image becomes a permanent record of the form state at that moment.
Related concepts
PDF rendering and PDF authoring are different problems. **Authoring** (Adobe Acrobat, Apple Pages export, LaTeX → PDF) writes PDF objects — pages, fonts, vector commands, embedded images. **Rendering** (Adobe Reader, Apple Preview, PDF.js, mutool) takes those objects and produces pixels for display or print. This tool is a renderer that captures the pixel output and saves it as PNG/JPEG, exactly like taking a screenshot of a PDF viewer — except scriptable, scale-controllable, and operating on the entire document.
**PDF.js**, the renderer this tool uses, is Mozilla's open-source implementation of the PDF specification. It started in 2011 as the default PDF viewer for Firefox; today it is bundled with Firefox, Chrome on Android, and many web-based PDF viewers (Slack file previews, Notion attachments, JIRA PDF view). It runs entirely in the browser via JavaScript and WebAssembly, supporting most of ISO 32000-1 — vector content, embedded raster images, OpenType fonts, encryption, basic forms, basic annotations. The tradeoff against native renderers (mutool, Ghostscript, Adobe) is speed and edge-case fidelity; very complex PDFs (CAD drawings, scientific papers with rare font subsets) render slightly differently or much more slowly.
Three adjacent concepts complete the picture. **OCR (Optical Character Recognition)** is the inverse — turning a rasterized image back into searchable text. `Tesseract` (Google's open-source OCR), `paddle-ocr`, AWS Textract, and Google Cloud Vision are common implementations. Workflows often chain PDF → image → OCR → text. **PDF/A** (ISO 19005) is an archival PDF subset; rasterizing a PDF/A document and re-saving as PDF/A means the document is now an "image-only" PDF/A-1, which loses the searchability that PDF/A-1b and above are meant to preserve. **Print rasterization** (Ghostscript, PostScript interpreters) is what physical printers do at print time — different code path, much higher DPI defaults (1200–2400), and output goes to printer pixels rather than image files. For prepress workflows, prefer the printer's native interpreter; for digital publishing, this tool is enough.
