Before—
After—
Saved—
Images—
Compression is judged on one number, which is exactly why this page starts with what it does not do. It re-samples embedded images down to the resolution they are actually printed at, and drops the document metadata. It does not touch text, vector drawing, or fonts — those are already compressed, and no browser can do better with them. On a document whose weight is in scans that is worth a great deal: the sample here goes from 301 KB to 127 KB at 150 dpi, and to 51 KB at screen resolution. On a text-only document it is worth nothing, and the tool says so instead of showing you a rounding error as if it were a result.
Step by step
01Open the document
Every embedded image is found, and the size it is actually drawn at is read out of the page's own drawing instructions — which is what turns 'this image is 4000 pixels' into 'this image is 660 dpi'.
02Pick the resolution it has to survive
Screen at 96 dpi, email at 150, print at 300. An image already below the target is left exactly as it was rather than re-encoded for nothing.
03Read the per-image report
Each image lists its stored pixels, the inches it is drawn across, and its effective dpi. Images a browser cannot decode are listed too, with the reason.
04Take the file, or find out there is nothing to take
The before-and-after is measured on the rewritten document. If nothing could be compressed, that is what the page says.
A worked compression
Two documents through the same tool at the same settings. One is a two-page scan; the other is a nine-page text report. Both numbers are what the tool prints.
Given
The same three presets on each document
delivery-note-scan.pdf 301 KB
Print 300 dpi q85 301 KB −0% already below 300 dpi
Email 150 dpi q75 127 KB −58%
Screen 96 dpi q70 51 KB −83%
quarterly-report.pdf 7.4 KB
any preset 7.4 KB 0% "this document embeds no images"
the scan's one image is drawn 7.38 inches wide, so its 1240 stored
pixels are 168 dpi — above 150, below 300The 300 dpi row is the one worth staring at. Nothing happened, because the image was already stored at 168 dpi for the size it is printed at — asking for 300 dpi cannot invent the pixels, so the honest answer is to leave the file alone. A tool that reported a saving there would have re-encoded a JPEG for the second time and handed back something slightly worse and barely smaller, which is what 'basic / strong / extreme' buttons frequently do. The text document is the other half of the same point: everything in a PDF that is not an image — the text operators, the vector paths, the font programs — is already Flate-compressed, and there is no browser-side move that beats it. Both answers are more useful than a number that always goes down.
Before you compress
Almost all the weight is images, and almost all images are oversized
A phone photograph dropped into a report is 4,000 pixels wide and printed six inches, which is 660 dpi for a page that will be printed at 300 and read at 96. Re-sampling to the resolution the page actually uses is where the bytes are, and it is the one part of PDF compression that can be done properly in a browser.
The resolution that matters is the drawn one, not the stored one
An image's pixel count says nothing on its own; dpi is that count divided by the inches it is drawn across. Getting it right means reading the transform out of the page's own drawing instructions, which is what lets the tool leave an already-appropriate image alone instead of re-encoding everything to a fixed size.
Text and vectors are already compressed
Content streams, font programs, and cross-reference tables are stored Flate-compressed — the same algorithm as a zip — and re-running it gains nothing. This is why a text-only PDF cannot be meaningfully shrunk by any tool that is not rasterising the pages, and why a service that halves one has quietly turned your text into pictures.
Only JPEG images can be reached from a browser
A JPEG inside a PDF is a JPEG, so its bytes go straight to the browser's decoder. A Flate-encoded bitmap would have to be decompressed and interpreted against its colour space by hand, and a CMYK JPEG cannot be decoded by a canvas at all. Both are listed as untouched with the reason rather than silently skipped.
Re-encoding a JPEG twice costs quality for nothing
Every lossy pass discards a little more, so re-encoding an image that is already at or below the target resolution makes it worse without making it smaller. An image below the target is left byte-identical here, and if a re-encode comes out larger than what it replaced, the original is kept.
Metadata is small, and worth removing anyway
Title, author, keywords, the producing application, and the XMP packet come to a few hundred bytes — nothing as compression. As disclosure it is often the most revealing part of the file, which is why the switch is on the panel next to the ones that matter for size.
The judgement call
What the document is for, and the target that follows from it.
Emailing a scanned form
150 dpi
It survives being printed on an office laser, and on the sample scan here it takes 301 KB down to 127 KB.
Attaching to a web page or a ticket
96 dpi
Nothing on a screen shows more than that, and it takes the same sample to 51 KB.
A document that will be professionally printed
300 dpi
The print standard. Frequently this changes nothing, which is the correct outcome and is reported as such.
A text document with no images
Nothing to do
Everything in it is already compressed. Any tool reporting a large saving is rasterising the pages and destroying the text.
The file is huge because it has 400 pages
Split it instead
Page count is not compressible. Splitting into parts that each fit an attachment limit is the operation that actually solves it.
You need it under a hard size limit
Split by file size
Compression cannot guarantee a ceiling; a split that builds and weighs each part can.
Reference
FAQ
It depends entirely on where its weight is. A scanned document is almost all image data and can lose more than half its size by re-sampling to 150 dpi — the sample in the Tinapps compress PDF tool goes from 301 KB to 127 KB. A text-only PDF cannot be meaningfully compressed at all, because its text, vectors, and fonts are already stored Flate-compressed.
Almost always because its weight is not in images. Text operators, vector paths, and font programs in a PDF are already Flate-compressed, so there is nothing left to squeeze; the other common case is a document whose images are already at or below the target resolution, where re-encoding them would cost quality without saving bytes. The Tinapps compress PDF tool reports which of the two it is rather than showing a rounding error as a result.
It reduces the resolution of the embedded images, which is the whole mechanism — a 660 dpi photograph re-sampled to 150 dpi looks identical on screen and identical on an office printer, and would show at a print shop. Text and vector drawing are untouched and stay perfectly sharp at any zoom, because they are not pixels.
Use a tool that runs in the browser. The Tinapps compress PDF tool decodes the embedded JPEGs with the browser's own image decoder, re-samples them on a canvas, and rewrites the document with pdf-lib — all in the page, so the file is never sent anywhere and there is no retention policy to trust.
96 dpi if it will only be read on a screen, 150 if it might be printed on an office printer, and 300 if it is going to a print shop. Choosing a target above what an image already stores changes nothing, which is the correct outcome — the pixels cannot be invented, and the Tinapps compress PDF tool leaves those images byte-identical rather than re-encoding them.
Because there is nothing left to compress. A PDF's content streams and font programs are stored with Flate — the same algorithm as a zip — and running it again gains nothing. Server tools that appear to halve a text PDF are usually rasterising the pages into images, which destroys the selectable text, the links, and the accessibility structure.
Those stored as JPEG, because their bytes can be handed straight to the browser's decoder. Flate-encoded bitmaps would have to be decompressed and interpreted against their colour space by hand, and CMYK JPEGs cannot be decoded by a canvas at all. The Tinapps compress PDF tool lists every image it could not reach along with the reason.
Only if you ask it to, and it is worth asking. The title, author, keywords, producing application, and the XMP packet together come to a few hundred bytes, so this is not a compression feature — but they routinely name a person, a template, and an internal file path, which is often more revealing than the document's own contents.
Images are decoded, re-sampled, and re-embedded entirely in your browser. The document is never uploaded, and the compressed copy exists only as the file you download.
Keep going
Split PDF
When a hard size ceiling is the real requirement, splitting guarantees it and compression cannot.
Image compressor
Shrink the photographs before they go into a document.
Delete pages
Sometimes the page carrying the giant scan is the one you do not need.
PDF tools
The rest of the category — merge, extract, rotate, and convert.