I needed a few figures out of a PDF for a coursework write-up. My method for the past year has been to export the page as an image and then crop. This time I zoomed in and the edges were soft — I hadn't cropped badly, the image had simply never been taken out of the file in the first place. There are two different operations hiding behind "get the image out of a PDF" and they produce different things, and the size relationship between them is the opposite of what I assumed.
I built a three-page PDF on purpose so I could reason about it: page 1 has a JPEG, page 2 has a PNG, page 3 reuses page 1's JPEG. The image appears four times on screen but there are only two actual resources inside, 1.1 MB total. Converting at 216 DPI in WebP gives page-001.webp at 178 KB, page-002.webp at 140 KB and page-003.webp at 161 KB, all 1788×2529, 480 KB total — three files, one per page, each a whole page, with the picture at whatever size it was laid out to be (420pt wide in my document, roughly 1260 px inside a 1788 px page). Extracting gives two files: image-001.jpg at 134 KB, labelled with both pages it appears on, and image-002.png at 970 KB on page 2, 1.08 MB total. Reused resources get exported once and you can see that on the result card without reading any docs. The extensions survive too — the JPEG stays a .jpg, the PNG stays a .png — which tells you nothing was re-encoded on the way out.
Why the rawer file is the bigger one
The size thing tripped me up. Extraction gives 1.08 MB, conversion gives 480 KB, so the rawer thing weighs more. It makes sense once you follow the steps: conversion scales the source image down to its 420pt layout width, rasterises at 216 DPI, then encodes the whole page as lossy WebP — downscale plus lossy encode, fewer pixels, fewer bytes. Extraction skips all of that and hands you whatever bytes the PDF stores, and that PNG was 970 KB going in. So file size here isn't a quality metric, it's a "has this been through a second pipeline" metric.
The twenty minutes I wasted
There was a detour in the middle. My first attempt used a different test file, a four-page report whose figures I'd drawn as SVG, and extraction returned 0 results. I assumed the tool was broken, reloaded, re-uploaded, tried a different browser, and only worked it out after switching files: SVG shapes become vector paths inside a PDF, not bitmap resources, so there was genuinely nothing to extract. What I want to point out is what it didn't do — it didn't fall back to screenshotting the page and calling that an extracted image. If it had, I'd have used the output as an original without ever questioning it, because it would have looked fine. Returning zero is the honest answer to "there are no images here", it just doesn't feel like it while you're sitting there reloading.
Which one you actually want
Choosing is straightforward once you know both exist. If you want what the page looks like — archiving, previews, dropping into a doc — convert. If you want the assets on the page, because you're going to reuse the figure or edit it or zoom in or feed it to something else, extract. If extraction returns nothing, the page is text and vectors, and whatever "image" you get from conversion is a repaint that you should know is a repaint. Cheap check: open the extracted file and the converted page at the same zoom and look at the glyph edges, the repainted one is softer.
One thing I still haven't figured out is that in my sample the PNG original is 970 KB and the JPEG original is 134 KB, seven times apart, and on the page they look about the same. My guess is that the PNG stored my noisy generated test image losslessly while the JPEG threw most of the noise away, but I haven't opened the file headers to check, so that's a guess and not a finding.
I used https://imging.ai/pdf-to-image/ — extraction is a mode toggle on the same panel, so running one file through both takes a couple of minutes.
Top comments (0)