What PDF to JPG actually does
A PDF is a vector layout — instructions for drawing a page. A JPG is a bitmap optimized for photographs. Converting one to the other means rendering: each page of your PDF is drawn fresh onto a canvas at the resolution you pick, then encoded as JPG. The PDF to JPG Converter produces one JPG per page. A 30-page report becomes 30 JPGs, numbered in reading order.
JPG is lossy. The encoder throws away image detail that the human eye is unlikely to notice, in exchange for much smaller files than the lossless equivalent (PNG). For pages dominated by photographs, that trade is usually invisible. For pages dominated by sharp text or thin lines, the artifacts can be noticeable around edges — a slight halo, a soft fringe where there should be a hard line. The quality slider gives you control over how aggressive that compression is.
The other thing to know up front: JPG does not support transparency. Anywhere your PDF page is transparent — and most aren't, but design exports sometimes are — the JPG output paints white. If you need transparency preserved, use PDF to PNG instead. For the typical case (an invoice, a report, a scanned document, a presentation export), white-on-transparent isn't an issue and JPG saves you a lot of bytes.
How to use it
The PDF to JPG Converter runs entirely in your browser. Your PDF never uploads. Drop a file, pick a DPI and a quality, click convert.
- Drop or pick your PDF. Up to 100 MB, max 200 pages.
- Choose the output resolution (72, 150, or 300 DPI) and JPG quality (60%, 80%, or 92%). Higher quality means a bigger file; lower quality means visible artifacts on text and edges.
- Click Convert to JPG. Each page is rendered to a canvas and exported as JPG — a few seconds for short PDFs, around 30-60 seconds for 100-page PDFs at high quality.
- Download individual pages with the JPG button on each thumbnail, or click Download all to grab everything in sequence.
No account. No email. No watermark on the output. No 5 MB cap. iLovePDF and SmallPDF will give you the same conversion and then nag you to subscribe before letting you do a second file. PDF24 and Sejda upload your PDF to a server first, which is the wrong default for any document you'd rather not hand over. The rendering work here happens in your browser, on your CPU, using Mozilla's PDF.js — the same library Firefox uses internally. Open your browser's network tab during conversion: zero outbound requests.
DPI and quality — the two knobs that matter
DPI controls how many pixels each page is rendered to. Quality controls how aggressively those pixels are then compressed by the JPG encoder. They're independent, and they multiply: high DPI plus high quality gives you the biggest, sharpest files. Low DPI plus low quality gives you the smallest, blurriest. Most real choices live somewhere in between.
| DPI | What it's for | A4 page pixel size | JPG size at 80% quality |
|---|---|---|---|
| 72 DPI | Email previews, on-screen viewing, web embedding | 595 x 842 | ~50-150 KB |
| 150 DPI | Office printer output, retina-screen viewing, slide decks | 1240 x 1754 | ~150-400 KB |
| 300 DPI | Commercial print, archive, enlarged display | 2480 x 3508 | ~500 KB-1.5 MB |
The quality slider then scales each of those numbers up or down:
| Quality | Visual impact | File size vs 92% | When to use |
|---|---|---|---|
| 92% | Visually identical to source | baseline | Final delivery, archiving, anything you'll print |
| 80% | Almost no visible difference; slight softening on text edges if you zoom in | ~40% smaller | Standard web and sharing default — this is the right pick most of the time |
| 60% | Visible artifacts on text edges and sharp transitions; fine for photo content | ~70% smaller | Previews, thumbnails, archive of scanned photos where compactness wins |
Default: 150 DPI at 80% quality is the right call for almost everything. Sharp on a retina screen, prints fine on a normal printer, and the file size is a fraction of what 300 DPI at 92% would give you. Reach for higher only when you have a specific reason.
A worked example
Suppose you have a 40-page scanned invoice archive — A4, mostly text, some logos, the occasional signature. You want to share it with your accountant as individual images so they can paste each one into their bookkeeping software (which doesn't accept PDFs).
At 72 DPI / 80% quality: each page is around 90 KB. Total bundle: ~3.6 MB. Pages look fine on screen at 100% zoom but soft if you zoom in. Acceptable for a quick share, not great for printing later.
At 150 DPI / 80% quality: each page is around 250 KB. Total bundle: ~10 MB. Pages are sharp on screen and look fine on a desktop printer. This is the sweet spot for the use case.
At 300 DPI / 92% quality: each page is around 1.2 MB. Total bundle: ~48 MB. Sharp at any zoom, prints commercially. Way more bytes than the accountant needs, and the upload may take a while.
For comparison, the same 40-page PDF saved as PNG at 150 DPI would weigh roughly 25-30 MB instead of 10 MB. JPG at 80% saves you about 60% of the file size, and for a document of mostly text and scans, the difference is invisible.
JPG, PNG, or WebP — which renderer should you use?
Three formats can come out of a "PDF page to image" workflow, and each is best at something different. The choice is rarely close once you know what the page contains and where it's going.
| Format | Lossless? | File size vs PNG | Picks itself when... |
|---|---|---|---|
| PNG | Yes | baseline (largest) | Text-heavy pages, line art, archiving, you'll edit further |
| JPG | No | ~25-60% smaller | Sharing, email, photo-heavy pages, embedding where size matters |
| WebP | Both modes | ~40-70% smaller | Web embedding on a modern site or app |
The most common case is "I just need each page as an image to share with someone or paste into something." For that, JPG at 150 DPI / 80% quality is almost always right — small files, good visible quality, and JPG is the format every operating system and every email client has supported since the 1990s. Pick PDF to PNG if the page is full of tiny text you'll need to enlarge later. Pick PDF to WebP if the destination is a website and page weight matters.
Render to image is not the same as extract images
This is the one thing people get wrong consistently, so it's worth saying clearly. There are two PDF-to-image jobs that sound identical and aren't.
Render each page as an image (what this tool does): the whole visible page — text, vector graphics, embedded photos, everything — is drawn flat onto a canvas at your chosen DPI. One JPG per page. The text inside becomes pixels; you can no longer select or copy it.
Extract the embedded images from a PDF (different tool): pulls out the photos that were placed inside the PDF, at their original resolution, as individual files. Text and vector shapes are ignored entirely. If a page has one logo and two product photos, you get three image files for that page — not one image of the whole page.
If you want the embedded photos back, use Extract PDF Images. If you want each page as a flat image you can show to someone, you're in the right place.
Edge cases worth knowing
A few things trip people up on the way through a PDF-to-JPG conversion.
Transparent backgrounds become white. JPG doesn't carry an alpha channel. Wherever your PDF page has transparency, we paint white before encoding. For 95% of real-world PDFs this never comes up — pages have a solid background. For design exports (a logo PDF on a transparent canvas, an Illustrator artboard), it matters. Use PDF to PNG if transparency has to survive.
Compression artifacts on small text. JPG works by grouping similar pixels into 8x8 blocks and encoding the block as a frequency pattern. Sharp transitions — the edge of a black letter on a white background — are where the algorithm struggles, and the result can look slightly fuzzy at low qualities. At 60% quality, you'll see it on body text if you zoom in. At 80%, it's there but invisible at normal viewing distance. At 92% it's effectively absent. If the page is mostly small text, either bump quality up or switch to PNG.
Scanned PDFs. A scanned PDF is already a bitmap. We render the page at whatever DPI you pick, but the result can't be sharper than the original scan. If the source is 100 DPI, asking for 300 DPI output just upscales — same detail, more bytes. Match the DPI to the source scan for the cleanest result.
Encrypted PDFs. Won't open. Unlock in Acrobat or Preview first.
Filled-in forms. Usually render fine. Digital signatures occasionally render as outlines or with gaps in PDF.js. If a page comes out wrong, flatten the form first with PDF Flatten Form and re-convert.
Mixed page sizes. A PDF with a cover spread, A4 body pages, and a fold-out at the end will give you JPGs of three different pixel sizes. Filenames are zero-padded with the page number so sort order matches reading order.
Why in-browser matters
iLovePDF, SmallPDF, PDF24, Sejda, Convertio, CloudConvert — all of them upload your PDF to their servers, render it there, and stream the JPGs back. That's a design choice, not a law of physics. For a marketing flyer it doesn't matter. For a tax return, a medical record, a signed contract, an employment letter, a bank statement — anything you'd think twice about emailing to a stranger — it matters quite a lot.
Browser-side rendering exists because PDF.js exists. Mozilla wrote it so Firefox could open PDFs without a plugin, and they open-sourced it. Every PDF you've ever opened in Firefox was rendered with the same library we use here. We aren't doing anything novel; we just chose not to throw the privacy property away by routing files through a server. The 10% Pledge — 10% of revenue to charity, off the top, audited quarterly — only works if the tool actually delivers without ads and friction in the way.
Related PDF tools
The PDF to JPG Converter is one of a stack of PDF tools, all of them browser-side. A few pair naturally:
- JPG to PDF — the reverse direction. Bundle a folder of JPGs back into one PDF.
- PDF to PNG — same job, lossless PNG output. Pick this when text is the priority or transparency must survive.
- PDF to WebP — same job, WebP output. Smaller files for web embedding.
- Extract PDF Images — pulls the original embedded images out. Different job from rendering.
- Split PDF — slice a big PDF into smaller PDFs before converting.
- PDF Merger — combine multiple PDFs into one.
- Image Compressor — shrink the JPGs further after conversion if you need to.
Frequently asked questions
Is my PDF actually private?
Yes. The conversion runs in your browser using PDF.js, the library Firefox uses to render PDFs. Your PDF bytes go from your file system to the browser's memory to the rendered canvas — never to a server. Open developer tools, switch to the network tab, then run a conversion. Zero outbound requests during the convert step.
JPG or PNG — which should I pick?
PNG is lossless — best for pages with sharp text, line art, screenshots, or anything you'll edit further. JPG is lossy with smaller files — best for sharing, embedding in documents, or photo-heavy pages where you don't notice the compression. If file size matters more than perfect pixels, pick JPG. If you'll re-edit or print at large sizes, pick PDF to PNG.
What does JPG quality actually do?
It controls how aggressively the encoder discards image detail to shrink the file. 92% keeps the page visually identical to the source at the cost of larger files. 80% is the standard web and print balance — files around 40% smaller than 92% with no visible difference at normal viewing distance. 60% is for archiving or previews — visible artifacts on text edges, but files 3-4x smaller than 92%.
What DPI should I pick?
72 DPI for previews and web embedding. 150 DPI for standard office printers and retina viewing. 300 DPI for commercial print or archive. Higher DPI multiplies file size: a 300 DPI page is roughly 4x the bytes of a 150 DPI page. Pick the lowest DPI that meets your use case. Most people want 150 DPI at 80% quality.
What's the maximum file size or page count?
100 MB and 200 pages per PDF. Past that, the browser struggles with memory at high DPI. For very large PDFs — a 500-page scanned book — split the PDF first with Split PDF or use a desktop tool.
Why are my JPG pages on a white background?
JPG doesn't support transparency. Anywhere the PDF page is transparent we paint white before rendering. If your source PDF has a colored background, that color shows through fine; if it has transparency (rare for normal PDFs, common for design exports), the transparent areas become white. If transparency has to survive, use PDF to PNG instead.
I want the photos that are inside the PDF, not pictures of each page. What do I use?
That's a different tool. This one renders each page as one flat image. To pull out the embedded photos at their original resolution as separate files, use Extract PDF Images.
Can I download all pages at once as a ZIP?
Not yet. The current Download all button triggers individual downloads in sequence, about 150 ms apart. Most browsers handle 10-50 sequential downloads fine. For 100+ pages, download in batches. A real ZIP option is on the roadmap.
Does this work on phones?
Yes, but slower. PDF.js runs the same on mobile browsers — for short PDFs (1-10 pages) it works fine. For long PDFs at high DPI and quality, the phone may run out of memory and the tab may crash. Stick to 150 DPI at 80% quality or lower on phones.