Lossless is the entire reason to pick PNG here
PNG stores pixels exactly. Feed it a page and every pixel that came out of the renderer is the pixel you get back, with no approximation anywhere. That is a narrower promise than it sounds, but it is the whole argument for choosing this tool over its JPEG sibling.
It matters most on the content PDFs are full of: text, table rules, box borders, arrows, flat fills. Those are hard-edged, high-contrast shapes, and photographic compression handles them badly, leaving faint ghosting around glyph edges and a slight mottling across areas that were meant to be one uniform colour. Nobody notices on a holiday snap. Everybody notices on a wiring diagram or a page of nine point footnotes blown up to inspect a figure.
The rendering itself is done by pdf.js, the engine Firefox uses for its built-in PDF viewer, so the page is drawn exactly as a reader would draw it. The difference between this tool and PDF to JPG is purely the encoder that photographs the finished canvas.
Rendering every page to PNG
- Drop your PDF into the box above, or click Choose a file.
- Pick a Resolution. Sharp (150 DPI, recommended) is the default and is right for screens, wikis and slide decks.
- Click Convert PDF to PNG. The bar advances as each page is drawn and encoded, with a short stretch at the end for packaging.
- Save the result: a single PNG for a one-page document, or one ZIP holding a numbered PNG for every page.
The white background baked behind every page
Every page is rendered onto a white canvas before encoding, and that decision is visible in the output rather than hidden inside it. The PNGs are fully opaque, so the alpha channel PNG is famous for is present but does nothing.
This is the right default because a PDF page has no background colour of its own. The specification leaves it undefined and every viewer paints it white, so a transparent render would produce images that look correct in one program and wrong in the next. The cost is that you cannot use this tool to lift a logo or a figure off a page with its transparency intact. For that you want the original asset, or Extract Images from PDF, which pulls the embedded bitmaps out at the pixel size they were stored at rather than re-photographing the page around them.
PNG or JPG for this particular document
The honest split is by content, not by preference.
Choose PNG when the page is mostly text, line art, a chart, a screenshot, a UI mockup, a technical drawing or anything with large areas of flat colour. Those are the cases where lossless compression works well, because runs of identical pixels are exactly what deflate is good at, and where lossy artefacts are most visible.
Choose JPG when the page is dominated by photographs or by a camera scan of paper, where continuous tone means lossless compression finds very little to exploit. The PNG of such a page comes out noticeably heavier than the JPG for a difference nobody can see at normal viewing size.
Notice also that this tool has one option and the JPG tool has two. There is no quality setting here because PNG has no quality axis to expose.
Pixel dimensions at 72, 150 and 300 DPI
PDF pages are measured in points at 72 to the inch, which makes the resolution setting a straight scale factor. At 72 DPI the render matches the page’s nominal size, so A4 lands near 595 by 842 pixels. At 150 DPI it is roughly 1240 by 1754, and at 300 DPI about 2480 by 3508.
Pick by what happens to the image next. Anything destined for a screen has nothing to gain above 150 DPI. Anything going to a printer or to somebody who will zoom in wants 300. The 72 DPI setting exists for thumbnails and quick previews, and for the case where you need a lot of pages quickly and small.
Remember that doubling DPI quadruples the pixel count, so the file sizes and the rendering time climb faster than the number suggests. PNG feels that more sharply than JPEG does, because it has no compression budget to fall back on.
Where the PNG route runs out of road
Three limits are worth knowing before you start. The whole document is converted, with no page picker, so extracting one figure from a long report means running Split PDF first. Multi-page results always arrive as one archive rather than loose files. And the text becomes pixels, so nothing in the output is selectable or searchable.
There is no size cap and no queue, because there is no server involved to impose one: the file is read from your device’s memory and rendered on a local canvas, and the only thing fetched over the network is the pdf.js worker script. The real ceiling is your device’s memory, since every encoded page has to be held until the archive can be assembled. For the rest of the toolkit see all PDF tools, or read the best PDF tools, compared.
