Does PDF Compress Images? Two Exporters, Tested

Only if the program that builds the PDF decides to, and my test caught both outcomes in one afternoon. Does PDF compress images? The format never forces it. On 2026-07-18 I sent the same 4.13 MB iPhone photo through two PDF exporters: LibreOffice returned it 71.1% smaller, re-encoded with its metadata gone, while img2pdf wrapped it without touching a pixel. The exporter decides, not the PDF.

Scope first: that is one reference photo, one day, one machine, two specific export paths at their defaults. Word, Acrobat, macOS Preview, Google Docs and every print to PDF driver each carry their own defaults and would each produce a different number. What I measured is the two ends of the range: a mainstream office export, and a converter built to never re-encode. Everything between them is documented below with sources, and the hub on which apps compress your images keeps every result in this series side by side.

Does PDF Compress Images? What I Measured

The answer split clean down the middle: one exporter compressed hard, the other changed nothing. Both results came from the same source file on the same day, which is the point. Nothing about the .pdf extension predicts what happens to a photo inside one.

The reference file and the two exporters

REF-A, the photo every app in this series meets, is a real iPhone photo: 4,332,705 bytes, 4032x3024, JPEG, with its EXIF block intact, the hidden metadata a camera writes into a file, including GPS coordinates and a timestamp. Keeping one consistent input is what lets this page sit next to the Word, Google Slides and Dropbox results and mean something.

The two exporters were picked to bracket the range. LibreOffice Draw at its default export settings stands in for the office suite path a normal person actually uses. img2pdf is a small command line converter with one design goal: put an image into a PDF without re-encoding it. If the PDF format itself compressed images, a tool like img2pdf could not exist.

The LibreOffice result: 71.1% smaller and rebuilt

LibreOffice returned a 1.19 MB JPEG at 2313x1734 where a 4.13 MB JPEG at 4032x3024 went in, 71.1% smaller. The whole exported PDF weighs 1,252,762 bytes, under a third of the original photo on its own. Two separate things happened on the way. The export downsampled first, rebuilding the photo on a smaller pixel grid to meet its default 300 DPI ceiling: 4032x3024 is 12.2 million pixels, 2313x1734 is 4.0 million, so roughly two thirds of the pixels were discarded. Then it re-encoded the survivors as a fresh JPEG. The EXIF block did not survive either step.

That is a LibreOffice result, not a PDF result. The same photo through a different exporter lands anywhere from untouched to far smaller, which the rest of this page maps.

The img2pdf result: the wrapper cost 1,457 bytes

img2pdf returned the same 4.13 MB and the same 4032x3024, zero percent smaller, no re-encode. The whole output PDF came to 4,334,162 bytes against a source photo of 4,332,705, meaning the entire PDF structure wrapped around my photo cost 1,457 bytes. That number answers the format question on its own: a PDF can carry a photo with no compression whatsoever, so whatever a PDF did to your images, the format did not do it. A tool did.

Why Does One PDF Tool Shrink Images and Another Keep Them Intact?

Because PDF is a container that offers compression without requiring it. The specification defines a menu of storage filters, some lossy, some lossless, and leaves every choice to the program writing the file. My two exporters read the same menu and ordered opposite things.

The seven ways a PDF can store an image

Every picture in a PDF lives as an Image XObject, a self contained stream with a declared filter, and the PDF 1.7 specification defines seven filters an image stream can use:

More than half that menu is lossless. A tool can store your photo byte for byte and still produce a perfectly valid, perfectly ordinary PDF.

JPEG passthrough, the route img2pdf took

A JPEG is already DCT encoded data, and the DCTDecode filter accepts that data as it stands. Wrap the existing bytes in an Image XObject, declare the filter, done. No decode, no re-encode, no new generation of loss; a PDF reader hands those bytes to the same kind of JPEG decoder a photo viewer would use. That is the passthrough path, and my 1,457 byte overhead measurement is what it looks like in practice.

Re-encoding, the route LibreOffice took

The other route decodes your photo to raw pixels, resamples the grid down to a target resolution, then encodes a brand new JPEG at whatever quality the export dialog holds. For a photo that started as a JPEG this is a second lossy generation on top of the camera's first one, the stacking damage explained in lossy versus lossless compression. Every mainstream office exporter defaults to some version of this route, and they differ mainly in how far down they sample.

Does PDF Compress Photos Differently From Text and Graphics?

Yes, and the split is the quiet rule of every PDF exporter: text and vector graphics travel lossless, photos take the lossy path. Your paragraphs and logos survive any export untouched. The photos are the only cargo at risk, which is exactly why this page tested a photo.

The reason is arithmetic. Text and line art compress beautifully under lossless Flate, being all repeated patterns and flat color. A 12 megapixel photo is millions of unique continuous tone values, and lossless methods barely dent it, so exporters reach for JPEG, which was built to throw away photographic detail eyes do not miss. So does PDF compress photos by default in the tools people actually use? Usually yes, and usually only the photos.

Downsampling and re-encoding are two separate hits

Downsampling cuts the pixel grid before any encoding starts, and Adobe's PDF Optimizer documentation describes the three methods Acrobat offers for it, bicubic interpolation being the default and the gentlest. My LibreOffice export took both hits: the grid went from 4032x3024 to 2313x1734, then the JPEG re-encode squeezed what remained. Cutting the grid is the same operation covered in reducing image resolution, performed silently on your behalf.

The page size illusion

A downsampled photo still displays at the same physical size, because the page layout defines the rectangle and the surviving pixels stretch to fill it. The document looks unchanged at a glance while carrying a third of the detail, which shows the moment anyone zooms or prints. And PDF image compression is a one way street: re-export at a higher DPI and you get a bigger file interpolated from the surviving pixels, never the original detail back. The original lives on your disk or nowhere.

Which PDF Exporters Compress Images by Default?

Nearly all of them, at defaults scattered from roughly 72 to 300 ppi. My measured pair spans the whole range, 71.1% removed to 0%, and every major tool's documented default lands somewhere between those two ends.

The Office exports: documented settings, disputed behavior

Word's PDF export runs its own compression pass, separate from the document's image settings. A Microsoft Q&A thread on Word's PDF export collects users measuring output capped near 200 dpi with High fidelity set and do not compress images checked, with Microsoft able to reproduce some reports and no fix shipped. The famous checkbox governs what Word stores inside the .docx, not what its PDF engine emits.

The contrast with my own series is sharp: a Word document held my photo byte identical, while its PDF exporter is where the documented risk concentrates. The question does PDF compress images gets a different answer on every row of that table, and Office is the row where documentation and behavior disagree hardest.

Acrobat presets: 150 ppi standard, 300 for print

Acrobat's export presets are published in the same Optimizer documentation cited above, and they explain most of the numbers floating around this topic:

The threshold column matters more than it looks. Presets fire only when the input resolution passes the trigger, so an image that already sits under the ceiling passes through the downsampler untouched. That detail becomes the practical fix two sections down.

Preview, Ghostscript and the aggressive end

macOS Preview's Reduce File Size filter crushes images to roughly 72 dpi, and Apple's Preview guide says outright that the result may be lower quality than the original; the plain Export as PDF path without that filter leaves images alone. Ghostscript, the open source engine behind plenty of free compress PDF websites, publishes its ladder: its PDF optimization guide maps /screen to about 72 dpi, /ebook to 150, and /printer and /prepress to 300. When a random website shrinks your PDF dramatically, one of these presets is usually what actually ran. Adobe's own marketing quotes reductions of more than 50 to 80% for image heavy files, which tells you exactly where the savings live: in the photos.

How to Stop a PDF From Compressing Images

Control the exporter, then verify its output once. Most advice on how to stop a PDF from compressing images ends at a checkbox; the verification half is what actually protects you, because the tools above include two documented cases of settings being ignored.

In Acrobat: the PDF Optimizer, not Save As

File, then Save As Other, then Optimized PDF opens the panel where every image control lives. Set the downsampling dropdowns to Off, set compression to retain existing, and check the option that skips recompression when it would grow the file. A plain Save As runs defaults you never saw.

In Word: set the options, then trust nothing

Set Default resolution to High fidelity and check do not compress images in file before any pictures go in. Then treat both as stated intentions rather than guarantees. The reports above show the PDF exporter overriding them, so if the output matters, check what it produced.

The two minute verification

Extract and compare. The poppler utility pdfimages, run as pdfimages -all yourfile.pdf out, pulls every embedded image stream out of a PDF unchanged. Compare the extracted files against your originals and the argument is over: smaller pixel dimensions mean downsampling fired, same dimensions with a different byte count mean a re-encode ran, and identical bytes mean a passthrough, the img2pdf behavior.

The guaranteed paths: img2pdf, or compress first

For a photo that must arrive intact, img2pdf gave the cleanest result I measured: 0% change, dimensions kept, 1,457 bytes of overhead. For every other workflow, decide the size before the exporter can. Compress the photo to the size the document actually needs, at a quality you chose, and the exporter's thresholds have little left to fire on, the way Acrobat's Standard preset leaves anything under its 225 ppi trigger untouched. The wider workflow of getting images into documents at sane sizes is covered in converting an image to PDF.

How Does the PDF Result Compare to the Other Apps I Tested?

The LibreOffice export lands mid pack among the platforms in this series, grouped with the renderers, while img2pdf joins the storage tools in the small club that returns bytes unchanged. Same photo, same day, measured on disk.

The pattern that holds across the whole series is container versus renderer. Storage treats a file as cargo: Google Drive and Dropbox returned my photo byte identical. A renderer makes your image part of a display surface and re-encodes it on the way in, which is how Google Slides took 77.8% of mine. PDF is the only entry that lives on both sides of that line, because a PDF is whatever its exporter made it: LibreOffice acted like a renderer, img2pdf acted like a container. The extension tells you nothing. The tool tells you everything.

Decide the Compression Before the PDF Does

My photo met two PDF exporters and got two opposite verdicts. That is the real lesson of the test: the compression decision will be made by whatever writes the file, unless you make it first.

Compress the photo before it meets an exporter and the decision is yours: quality 80 takes a typical phone photo down 60 to 80% with nothing visible lost at normal size, up to 25 MB per image, 30 at a time, free. It strips the EXIF block by default too, so the PDF you share is not carrying GPS coordinates inside its image streams. My LibreOffice export stripped EXIF as a side effect of re-encoding, but a passthrough embed keeps whatever the file carries, which is exactly why stripping it yourself first matters.

Then build the PDF with any tool you like: hand the exporter a photo that already fits and there is nothing left for its defaults to take. The wider method lives in how to compress an image.