Most "extract images from PDF" tools are just screenshotting the page

If you have ever pulled "images" out of a PDF and they looked soft, that was not extraction. That was a render.

A PDF can hold a real JPEG or PNG as an XObject. The bytes are already in the file. You can lift them out at the original resolution. A lot of online tools do not do that. They draw each page to a canvas and export the canvas. You get a picture of the page, including the text around the photo, at whatever DPI they picked.

Those are different jobs.

How to tell which one you got

• Extracted: the file that comes out is a JPEG or PNG. Dimensions match the photo the author placed, not the page. A 4000px camera original stays 4000px.
• Rendered: you get one image per page. Text is flattened into pixels. Cropping the photo later is on you.

If the download is page-1.png and it includes the header and the footer, it was a screenshot.

Why the distinction exists

PDF.js (and anything sitting on a PDF parser) can walk the page's XObject map and hand you the raw stream. That is a copy. Rendering the page through a canvas is a photograph of the layout. Both are useful. Only one answers "get the pictures out of this deck."

I built the extract path because that is the query people type. The tool is here:

https://imissfiles.com/extract-pdf-images/

It runs in the tab. No upload. Open Network and watch — same check I wrote about last time.

What still fails

• A "photo" that is actually a bunch of vector shapes will not come out as an image. There is no image stream.
• Some PDFs wrap images in a form XObject. Those need an extra walk. Easy to miss on the first pass.
• A scanned page is one giant image. Extracting it just gives you the scan. That is correct, and also not what people meant.

If you only needed the pictures, use an extractor. If you needed a picture of the page, use a renderer. Do not let a site blur those together and call it a feature.

Comments

[Raknaos]

The extract-vs-render distinction is the one most "PDF tools" get wrong in the worst way: the output looks fine at screen size, so nobody notices the original 4000px XObject got resampled to a 150 DPI page screenshot until someone tries to print or crop.

One thing I'd add from running my own pipeline: the tricky middle case is images that are stored as raw samples with a colorspace/SMask pair rather than a neat embedded JPEG. Lifting those "at original resolution" means re-encoding the mask back in, and plenty of extractors silently drop transparency there. Are you handling smask compositing in your path, or restricting to the DCT/JPX XObject case?