Export PDF Pages as JPG Images: What Gets Preserved?

Recovering an embedded image means reaching into the PDF's internal structure, finding the stored image object a designer placed there, and writing it out as its own file. If it succeeds you get the asset at its original pixel dimensions, without the surrounding page.

Rendering a page means drawing the page the way a viewer draws it—text, vectors, photographs, annotations and all—and saving that drawing as a picture. You get one image per page, at whatever resolution the renderer used, containing everything on the page including the parts that were never images to begin with.

FiloTool renders every page of the PDF and gives you one JPG per page. Rendering happens at twice the PDF's nominal page scale, which for a document authored at the usual 72 points per inch works out around 144 pixels per inch, and each page is encoded as JPEG at quality 0.92.

Those two numbers explain most of the results people find surprising. The resolution is chosen to stay comfortably within browser memory on an ordinary device rather than to maximise fidelity, so fine print is legible but not archival. And because the output is JPEG, it is lossy and opaque: there is no transparency in the result regardless of what the page contained.

It is reasonable to ask why any tool would render pages when it could just pull the originals out. The answer is that "the original" frequently is not a single retrievable file. A PDF can slice one photograph into a grid of separate image objects, store a picture and its transparency as two separate streams that only mean something combined, apply a colour transform at draw time, or place an image far larger than the visible area and clip it to a small window.

In those cases there is no single object that corresponds to what you saw on the page. A recovered object can come out tiled, oddly coloured, missing its mask, or much larger than the region it appeared in. Page rendering sidesteps all of it by asking the same question your PDF viewer answers: what does this page look like?

The rendered JPG is a faithful picture of the page, which is a genuine strength — overlays, annotations drawn into the page, stamps and watermarks all appear exactly as a reader would see them, and nothing is silently omitted because it was not an image.

Most disappointment with this workflow comes from a goal mismatch rather than a defect, so it is worth naming the goal first.

If you want a picture of each page for a slide, a preview or a thumbnail, this is the right workflow, and PDF to Image is the same engine with format choices if you would rather have PNG. If you want the words rather than the appearance, use PDF to Text, which pulls the embedded text layer directly and avoids rasterising anything. If the PDF is a scan with no text layer, the text has to be recognised from pixels instead, which is what OCR PDF is for.

And if you genuinely need the original embedded asset — a print-resolution photograph for reuse elsewhere — the honest answer is that no browser-local FiloTool workflow currently does that, and asking whoever produced the document for the source file will get you a better result than any recovery attempt.

Because resolution is fixed, the useful levers are on the input side and on what you do afterwards. A PDF whose pages are physically larger renders to more pixels at the same scale factor, so a document laid out at A3 produces a bigger image than the same content at A5.

After export, resist re-saving the JPGs repeatedly, since each save re-encodes lossily and the softening compounds. If the images need to be smaller for sharing, resize or compress once from the original export rather than iterating on a file you already exported twice.

Every page becomes an image, so a long document produces a lot of files and a correspondingly large download. Rendering is done in your browser, which means available device memory is the real ceiling — a very long or very graphically complex PDF can exhaust it, and page-heavy documents are the usual cause. Reducing an image-dense source with Compress PDF first can bring such a document within reach, at the cost of some detail in the render.

Encrypted or password-protected PDFs are not opened by this workflow; a file you are authorised to open must be unlocked first. And because the export is a rendering rather than a copy, the result reflects how the page was drawn, including any fonts that were substituted at draw time.