PDF to JPG and back: what you lose on the round trip

Turning a PDF page into an image means rasterising it — drawing the page at a chosen resolution into a pixel grid. Text that was stored as text becomes a picture of text, and from that moment it is no longer selectable, searchable or editable. There is no way to reverse this; the text information is genuinely gone.

That is not a defect. It is what a raster image is. The practical consequence is that you should pick the resolution at the moment of rendering, because you cannot add detail later. Rendering at 72 DPI and then upscaling to make it look bigger produces a soft, blurred page with more pixels than before and no more information.

Our tool renders with pdf.js — the same engine Firefox uses to display PDFs — at a resolution you choose, and writes one JPG per page. Multi-page documents produce multiple files, delivered as a single zip download rather than a pile of individual downloads.

Going the other way, JPG and PNG files are simply embedded into PDF pages, and the image bytes are copied as they are. A 200 KB JPEG in becomes a 200 KB JPEG inside the PDF, plus a handful of bytes of page description. Nothing is re-compressed, so there is no quality loss at all.

This is why rebuilding a document from page images works so well: if those page images are good, the PDF is good. And it is also why the file size of an image-based PDF is roughly the sum of its images — there is no compression magic to be had at that step, since the images were already compressed.

The one decision that matters is page size. Fit-to-image pages give the smallest file; A4 pages give the most printable result. Neither changes the pixels.

Every JPEG re-encode loses a little information, and the loss compounds. Render a PDF page to JPEG at quality 75, convert that JPEG back into a PDF, then render again at quality 75, and the second image is visibly worse than the first — artefacts from processing the first image are themselves processed a second time.

Rules that avoid it: when you need both a PDF and a JPG, produce them from the original file rather than from each other. When you must re-encode, go up in quality rather than staying level, so that one generation costs as little as possible. And never use JPEG for intermediate files — work from the PDF or from a PNG, and encode to JPEG only as the last step.

The two kinds of PDF look identical on screen and behave completely differently in every other respect.

A text PDF exports from a word processor or a portal contains fonts and character data. It is a few tens of kilobytes per page, its text can be selected and searched, it can be compressed losslessly, and converting it to an image throws all of that away. If you have a choice, keep it as text and render only if a portal forces you to.

An image PDF comes from a scanner or a phone camera. Each page is one photograph, typically 200 KB to 2 MB, with no text layer. Its quality is fixed at capture time, and its size can only be reduced by re-encoding, which loses a little more each time. Recognising which one you are holding tells you immediately what is possible: lossless shrinking for the first, a quality decision for the second.

This is the most common dead end in the whole workflow, and the answer usually is not a conversion at all. Several things are worth trying before you compromise the document.

• Read the requirement again. Portals that say "JPG" often mean "image", and accept PNG; portals that cap the count at one file often have a separate, higher limit for PDFs somewhere else in the form.
• Combine vertically. For a short document — two or three pages — stacking pages into a single tall image is acceptable and readable on phones. Six pages of dense text are not; the resulting image is either enormous or illegible.
• Reduce to the essential pages first. A six-page bundle where only two pages satisfy the requirement should be a two-page bundle; split the PDF first, then render.
• Check for a PDF upload path in a different section. Photo and signature slots want images; the document-proof slot usually accepts PDF and often has a larger size allowance.

JPEG files from a phone carry EXIF tags: camera model, timestamp, and often GPS coordinates. Rendering a PDF page to JPG produces a clean image with no EXIF, which is usually desirable. Going the other way, an embedded JPEG inside a PDF keeps whatever tags it had, though PDF viewers rarely surface them.

If you are sharing a photograph of a document and would rather not disclose where it was taken, convert it to an image format or re-save it through any tool that drops EXIF — every re-encode does — or simply use our compressor, which writes fresh headers and discards the metadata block entirely.