How to Convert PDF Pages into High-Resolution JPG & PNG Images

The resolution you actually get

PDF pages are measured in points, and there are 72 points to an inch. The renderer draws each page at double that, so every inch of the original becomes 144 pixels. A US Letter page arrives at about 1224 by 1584 pixels. A4 lands near 1191 by 1684. That is comfortably sharp for a slide, a web embed, a forum post or a screenshot in a bug report, and it is what you get whether you ask for PNG or JPG.

It is not 300 DPI, and there is no box to type 300 into. The scale is fixed. Worth knowing too: the tool renders the page, it does not reach inside the file and pull out the pictures that are already there. If a page holds a 600 DPI scan, what comes back is a 144 pixel per inch rendering of that scan, not the original image at its own resolution.

PNG or JPG, and the transparency trap

JPG output paints the canvas white before the page is drawn, then encodes at quality 0.92. Files are small, photo-heavy pages look good, and sharp black text picks up a faint halo if you zoom right in.

PNG is lossless and skips the white fill. Most PDFs never paint their own background, which means the PNG you get back has a transparent one. Drop that on a white slide and it looks perfect. Drop it on a dark slide and the text vanishes into the background, and a few image viewers render the transparency as solid black. If anything downstream is going to place the image on a colour, choose JPG or flatten the PNG onto white yourself.

You get every page, in a ZIP

The tool renders the whole document and packages the results as one ZIP, a single image per page, each named after the source file with the page number on the end. There is no page range field. Wanting page 47 of an 80 page report still gets you 80 images, and you fish out the one you needed. It takes one PDF at a time, up to 100 MB.

What rasterizing costs you

Converting a page to a picture of a page throws several things away, permanently:

• Text stops being text. You cannot search it, select it or copy it, and a screen reader has nothing to read. Run the page through OCR later and you are guessing at characters that used to be stated exactly.
• Links, form fields, annotations and bookmarks are gone. Only the visible ink survives.
• Vector artwork gets baked in at 144 pixels per inch. Diagrams and thin rules that were infinitely scalable now have an edge you can see when you enlarge them.
• File size often goes up, not down. A page of plain black text saved as PNG can easily outweigh the entire PDF it came from, because the PDF stored a few kilobytes of glyph instructions and the PNG stores two million pixels.

Where it gets slow

Pages render one after another, and each finished image sits in the tab's memory until the whole set is zipped. A short document is instant. A few hundred pages is a different experience: the rendering loop is the slow part, and memory is the wall you hit first. Phones run out sooner than laptops do. If a long document stalls the tab, close the other tabs and try it again, or split the PDF first.

None of that involves a server. The rendering runs in the page you already have open, so your document never travels. The rendering engine itself is fetched from a public CDN the first time you use the tool, which is a script coming to you rather than a file going out.

When a desktop tool is the better answer

Anything headed for print needs a real command line renderer. Ghostscript and pdftoppm let you name the resolution outright, ask for pages 12 through 18 only, and render straight to CMYK so a printer gets what it expects. The same goes for a nightly job over a folder of hundreds of files, or for pulling out the embedded images at their original resolution rather than a rendering of them, which is a different operation with different tools. For a few pages you want to paste into a deck this afternoon, the browser wins on effort.