Embedded bitmaps, not a rendering of the page
There are two completely different things people mean by getting images out of a PDF, and picking the wrong one wastes an afternoon.
The first is turning each page into a picture. That gives you the layout: headers, margins, body text and photos flattened together into one raster at whatever resolution you asked for. Convert PDF to JPG and Convert PDF to PNG do that, at 72, 150 or 300 DPI.
The second is what this page does. It walks each page’s drawing instructions, finds the operators that paint an embedded bitmap, resolves the image object behind each one, and copies the pixels out at the size they were stored. If a photographer put a 4000-pixel-wide shot into a supplier catalogue, 4000 pixels wide is what comes back, regardless of the postage-stamp box it was displayed in. No page furniture, no re-rasterisation, no DPI choice to get wrong.
- Drop a PDF onto the box above, or press Choose a file. One document per run; this is not a batch page.
- Set Which images. Keep All images (including tiny ones) to take everything, choose Skip tiny images (under 32px) to lose spacer pixels and bullet dots, or Only large images (256px and up) when you want just the photographs.
- Press Extract Images from PDF and watch the bar, which advances a page at a time.
- Download the result: a single PNG when the document held one image, or a ZIP named after your PDF when it held several.
Every output is a lossless RGBA PNG, and that costs bytes
The encoder here is written into the tool rather than borrowed from a canvas. It emits an 8-bit truecolour-with-alpha PNG, filter type None on every scanline, with the image data compressed as a real zlib stream and the chunk checksums calculated with the same routine the site’s ZIP writer uses.
Lossless is the point. A photograph stored inside a PDF as a JPEG has already paid its compression tax once; decoding it and re-encoding it as another JPEG would charge it a second time for nothing. PNG copies the decoded pixels out exactly as they are.
The honest cost is file size. No scanline filtering means the compressor has less structure to exploit, and forcing an alpha channel means four bytes per pixel even for an opaque photo. A tightly compressed JPEG inside the PDF can easily come out as a PNG several times its size. That is a fair trade when you are recovering an original asset, and a bad one if you just wanted something small for a web page, in which case run the result through an image compressor afterwards.
Repeated images are collected once, under the page that drew them first
PDFs reuse aggressively. A letterhead logo is stored once and painted on every page; a table’s cell shading might be one tiny bitmap tiled hundreds of times. Extracting each paint operation literally would bury the two photographs you actually wanted under three hundred duplicates.
So each image object is remembered by the identifier the engine gives it, and the second and every later reference is skipped. The copy you keep is filed under the first page that used it, which is why the page numbers in the file names can jump: page 7 might contribute nothing simply because everything it draws was already collected earlier.
Inline images, which are written directly into the page’s content stream and have no identifier to remember, are de-duplicated differently, by a short signature made from their dimensions plus the leading bytes of their pixel data. It is a heuristic rather than a guarantee, and it is only reached by inline images, which are rare and small in practice.
What gets skipped, and why nothing broken is ever handed back
Vector artwork is not extractable, full stop. Charts, diagrams, icons and most logos are drawn from paths and text rather than stored as pixels, so there is no bitmap in the file to pull out. Rendering the page is the only route to those.
Stencil image masks are excluded deliberately. A one-bit mask paints ink through a shape; it is a drawing instruction, not a picture of anything, and a ZIP full of black silhouettes helps nobody.
Beyond that, the extraction is written to skip rather than to fail. An image object that never resolves within its timeout, or one whose pixel format the converter does not recognise, such as an unusual colour space, is passed over and the run carries on with the next one. Three raw layouts are handled directly, being RGBA, 24-bit RGB expanded to opaque RGBA, and packed one-bit greyscale unpacked a bit at a time. Anything the engine decoded natively into a browser image object instead takes a short detour through a canvas to read its pixels back.
If a document yields nothing at all, the run ends in an error rather than in an empty download. A text-only report, a vector-only diagram sheet and a PDF whose images all fell below your size filter will each land there, so a failed run is often a signal to try All images (including tiny ones) before concluding the file is empty.
Naming, packaging, and what the engine costs you
File names are image-p<page>-<sequence>.png, with the sequence zero-padded to three digits and restarted on every page. image-p3-002.png is the second image kept on page 3. Because the sequence counts only the images that survived de-duplication and the size filter, it numbers what you were given from that page rather than everything drawn on it.
A document that yields exactly one image gives you that PNG on its own, still under its image-p... name. Two or more are bundled into a single ZIP named after your PDF with -images appended, which is the only place the original document name appears.
The parsing engine is the same open-source one Firefox uses to display PDFs, and its background worker is fetched from a CDN at the pinned installed version the first time you run the tool. That fetch aside, the extraction makes no network requests at all; the document is read from your disk into memory and stays there. Scanned documents are the best case for this tool, since a scan is usually one large bitmap per page, which is precisely what it is built to find. If it is the words you are after rather than the scan, PDF to Text pulls the text layer out instead, and the rest of the document tools sit on the pdf hub.