How to Save Images from a PDF: What Page Rendering Can and Cannot Give You
When people say they want to save images from a PDF, they usually mean one of two quite different things, and the tools that serve them are different too. The first meaning is rendering: turn each page into a picture of that page, so a three-page report becomes three image files that look exactly like the printed sheets. The second meaning is extraction: reach inside the file, find the individual photographs and diagrams the author embedded, and pull them out at their original resolution.
PDF to Image and PDF to JPG on PdfWill do the first thing. They render whole pages. What you get back is a faithful picture of each page including its text, margins, headers and any surrounding layout, at the resolution you choose. This is the right answer surprisingly often: for pasting a page into a slide deck, posting a chart to a chat thread, attaching a proof to a ticket, or feeding a page into a tool that only accepts images. It is not, however, a way to get the author's original photo file back.
If what you actually need is one picture from the middle of a page, the practical route is to render first and crop second. Export the page at a high resolution so you have pixels to spare, then trim away everything around the picture. The crop tool works on the PDF before rendering if the image occupies a clean rectangular region of the page, which is often the case for full-width figures and charts. Otherwise any image editor, or even your operating system screenshot tool, finishes the job in seconds.
Be honest with yourself about the quality ceiling of that approach. A rendered page is a rasterisation of how the page looks, so a photograph that was embedded at 3000 pixels wide but printed at 8 centimetres will come back at whatever resolution you rendered, not at its original size. For a slide or a web post that is entirely fine. For reprinting a photograph at large format, or for any workflow where the original file quality matters, ask the document author for the source asset instead. That is not a limitation you can work around by exporting harder.
True embedded-image extraction is a separate technical operation: parsing the file structure, walking the resource dictionaries, and writing out each image object as its own file. It also produces messy results in practice, because a single visible picture is frequently stored as several tiles, a separate transparency mask, and a colour profile that only means something in context. That is why the render-and-crop route remains the pragmatic default for most people, and why it is worth knowing exactly which of the two things you are getting.