Convert PDF pages to high-quality PNG or JPEG images at custom DPI. Batch-convert whole documents or pick pages — processed privately in your browser.
A PDF page is a set of drawing instructions. An image is a grid of pixels. Converting one to the other means rendering the page — running those instructions and capturing the result — and the only decision that really matters is how big a grid you capture it into. Get that wrong and the export looks soft, blocky, or absurdly large. This page explains the choice, then the rest of what the tool does.
You drop in a PDF, pick PNG or JPG and a resolution scale, and press Convert. Every page is rendered in turn, with a running counter so you can see progress on a long document, and the results appear as a grid of thumbnails. Each one has its own Save button, and there is a Download All if you want the lot. The PDF is read and rendered entirely inside your browser tab — the document is never uploaded to a server — using the Mozilla PDF.js rendering engine, the same engine Firefox uses to display PDFs.
The tool offers four scales: 1x, 1.5x, 2x and 3x, with 2x selected by default. These are multipliers on the page's natural size, and the natural size is fixed by the PDF specification: PDF measures pages in points, at 72 points to the inch. So 1x renders at 72 DPI, and each step up multiplies from there.
That makes the output dimensions completely predictable. For the two page sizes you are most likely to be holding:
| Scale | Effective DPI | US Letter (8.5 × 11 in) | A4 (210 × 297 mm) |
|---|---|---|---|
| 1x | 72 DPI | 612 × 792 px | 595 × 842 px |
| 1.5x | 108 DPI | 918 × 1188 px | 893 × 1263 px |
| 2x (default) | 144 DPI | 1224 × 1584 px | 1190 × 1684 px |
| 3x | 216 DPI | 1836 × 2376 px | 1785 × 2526 px |
Match the number to the destination rather than reaching for the maximum every time:
This is the single most common complaint about PDF-to-image conversion, and it is not a bug. Most PDFs store text as font instructions and diagrams as vector paths. Vector data has no resolution — that is the whole point of it — so a PDF looks equally sharp whether you view it at 100% or 800%. The moment you export to PNG or JPG you fix a resolution, and everything above it is gone permanently.
Concretely: export a page at 1x and you get a 612-pixel-wide image. If you then place that image in a slide at full width on a 1920-pixel-wide projector, the software has to stretch 612 pixels across roughly 1900, and the text edges turn into grey mush. Nothing recovers it afterwards — upscaling in an image editor invents pixels, it does not restore detail. The fix is always to go back and re-export at a higher scale, which costs you nothing but a few seconds.
The reverse mistake is real too. A 40-page report exported at 3x produces forty images of around 1800 × 2400 pixels. If those are going into an email, you have made the problem worse rather than better.
One honest limit: 3x works out to 216 DPI, which is below the 300 DPI convention for print work. For on-screen use, tickets, slides and documentation that is comfortably enough. If something genuinely needs to go to a commercial printer as a raster image, this browser-based export is not the right last step — and in almost every case the better answer is to send the PDF itself, which stays vector and prints at the press's full resolution.
Both are offered, and the choice follows the content of the page rather than any general preference.
PNG is lossless. Every pixel comes out exactly as rendered, which means text edges stay clean and thin table rules stay thin. It is the right choice for anything dominated by text, line art, charts, screenshots or diagrams — which is most business PDFs. The cost is file size: a lossless encoding of a detailed page can be substantially larger than a JPEG of the same page.
JPG is lossy, and it is designed for photographs. On a photographic page it is excellent and much smaller than PNG. On a page of black text on white it is the wrong tool: JPEG compression works on blocks and struggles with hard edges, so you get faint grey halos and speckling around every letter — the artefact usually described as ringing. It is most visible exactly where you least want it, on small text.
Choose JPG and a quality slider appears, running from 10% to 100% in 5% steps, set to 85% by default. That number is passed straight to the browser's JPEG encoder. 85% is a well-chosen default: artefacts are hard to see on most content, and the file is a fraction of the lossless size. Dropping toward the bottom of the range shrinks files aggressively but the damage becomes obvious quickly on any page with text. Pushing to 100% inflates the file substantially for a difference you will struggle to see, so if you find yourself reaching for 100% you probably wanted PNG.
Only these two formats are available. There is no WebP, TIFF, SVG or multi-page output here, and no option to produce a single tall image of the whole document.
Worth setting expectations clearly: the tool always renders every page. There is no page range to type and no way to convert only page 7. What you control is which of the rendered pages you keep.
After conversion, each page appears as a thumbnail in a grid, labelled with its page number, with a Save button beneath it. Clicking Save downloads that one image. That is the per-page workflow, and for the common case — one diagram out of a twelve-page report — it is exactly right: convert, find the page in the grid, save it, done.
Download All saves every page. It is worth knowing what it does mechanically, because it surprises people: it triggers the individual downloads one after another rather than building a ZIP archive. Browsers treat a burst of downloads from one page as something to check, so the first time you use it you will probably see a permission prompt asking whether the site may download multiple files. Allow it and the rest arrive. On a long document that is a lot of separate files landing in your downloads folder at once.
Filenames are derived from the source. A file named report.pdf produces report_page_1.png, report_page_2.png and so on, so the numbering stays intact when they are sorted alphabetically in a folder — up to page 9, at which point report_page_10.png sorts before report_page_2.png. If ordering matters downstream, rename with zero padding after export.
Every rendered page is held in the tab — both a preview and the encoded image data — until you reset or reload. That memory adds up, and it is the practical ceiling on this tool. A ten-page document at 3x is fine. A two-hundred-page document at 3x asks the browser to hold two hundred large images at once, and the failure mode is an unresponsive tab rather than a tidy error message. If you have a long document and only need a few pages, convert at a lower scale first to find them, or reduce the document before converting.
Rendering time scales with both page count and the square of the scale factor: 3x renders roughly nine times as many pixels per page as 1x. The counter on the button shows which page it is on, so a slow run is visibly progressing rather than hung.
| Message | What it means |
|---|---|
| Please upload a PDF file. | The browser did not identify the file as application/pdf. Renaming another file type to .pdf does not make it one. |
| Failed to read PDF. The file may be corrupted or encrypted. | The renderer could not open the document. Almost always a password-protected PDF — there is nowhere to enter a password here, so open it in a reader with the password and save an unprotected copy first. Otherwise, a damaged or unusually structured file. |
| Failed to convert PDF to images. | The document opened but rendering failed part-way. Try a lower scale, which is both faster and much less memory-hungry. |
No. The PDF is read from disk by your browser, parsed and rendered in the tab, and the resulting images are created locally as blobs and handed to your downloads folder. Nothing about the document's contents is transmitted. For completeness: the rendering engine's background worker script is fetched from a public JavaScript CDN the first time it is needed, as is normal for a browser-based PDF renderer, but that is program code coming down — your document does not go up.
No, and this is inherent rather than a limitation of the tool. Rasterising a page converts text into pixels. If you need selectable text out of a PDF, you want text extraction, not image conversion.
What you get is the rendered appearance of the page. Content that the renderer draws as part of the page will be in the image; interactive layers are not preserved as anything but their appearance, because an image has no interactivity to preserve. If a stamp or filled form value matters, check the thumbnail before you rely on the export.
Not here — this tool runs one direction only. Note that the round trip is not lossless in any case: once a page has been rasterised, the text and vectors are gone, and wrapping the pixels back into a PDF gives you a picture of a page rather than the page.
Most likely the scale, not the quality setting. Doubling the scale quadruples the pixel count, and file size follows pixel count far more strongly than it follows the quality slider. Drop from 3x to 2x before you start reducing quality — you will usually get a smaller file that looks better.