A designer sent me a finished brochure as a PDF and, a week later, asked for "the product photos from it" for the website. The originals were on a laptop she no longer had. The photos existed in exactly one place: embedded in that PDF. What she did next is what most people do — opened the PDF, zoomed in, and took screenshots. What she got was screen-resolution crops with viewer borders, at whatever size her window happened to be.
The images inside a PDF are files in their own right, stored in the document's structure. Extraction pulls those stored files out untouched. Rendering (which is what a screenshot is) re-creates a picture of the page at your screen's resolution. For anything you plan to reuse, the difference is the whole game.
Extraction vs. the other things people do
- Screenshot / snipping tool: captures pixels at display resolution, includes whatever zoom and cropping you happened to have, and bakes in any downscaling the viewer did. Fine for showing someone where a button is; wrong for source material.
- Export page as image: renders the whole page at a resolution you choose. Good for slides and previews, but you get the page — layout, margins, text and all — not the photo.
- Extract images: walks the PDF's object structure and writes out each embedded image stream as its own file, at its stored resolution and in (or near) its stored format. This is the one that gives you back the closest thing to the originals.
I use an extract-images tool for the one-off jobs; in a pipeline, pdfimages -all document.pdf out/ from the poppler suite does the same thing and lists what it found with pdfimages -list before you commit.
What "original" honestly means here
Extraction gives you the image as stored in the PDF, which is not always the image as photographed. Three realities to set expectations:
- The PDF may already hold a downscaled copy. Many generators shrink images to a target DPI when the PDF is made. If the brochure was produced for print, you are in luck — print pipelines store 300 DPI. If it was produced for email, the embedded photo might be 800 pixels wide and no tool can invent the rest.
- Color spaces travel with the file. Print PDFs often store images as CMYK. Extracted as-is, they can look wrong in browsers until converted to sRGB. Check one image before batch-converting two hundred.
- Masks and soft transparency extract as separate pieces. A photo with a soft-edged cutout may come out as an image plus a grayscale mask. That is not corruption; it is how the PDF stored it, and the pair recombines in an image editor.
The thirty-second check before you promise anything
Run the list first (pdfimages -list, or the count and dimensions any extraction tool shows you) and read the resolutions. If the stored images are at or above the size you need, extraction will make you look like a hero. If they are below it, say so now — and go ask for the originals while someone may still have them, instead of delivering upscaled screenshots with confidence.
The PDF is not a dead end for assets. It is a container that happens to be carrying files — and on the day the originals are gone, it is the only backup nobody remembered making.
Top comments (0)