Shrink a PDF small enough to email.
Add a PDF and download a smaller version. The saving comes from stripping unused objects and rewriting the file structure, so text and layout are untouched.
Add the PDF. The panel shows its current size, which is the number you are trying to reduce.
The tool rewrites the file structure and reports the actual saving. It tells you honestly when a file was already efficient rather than claiming a reduction it did not achieve.
The result should look identical, because nothing is re-encoded. If the saving was small, the section below explains why, and what would actually reduce that particular file.
In almost every case, images. A page of text is a few kilobytes of drawing instructions plus a font subset. A single full-page 300dpi colour scan is several megabytes on its own. Before deciding a file is bloated, work out roughly what it should weigh: text-only pages at a few tens of kilobytes each, photographic pages at a megabyte or more.
This tool rewrites the file with object streams, which pack many small objects together and compress them as a unit rather than individually. It also drops objects nothing references any more — orphaned resources left behind by editing, old versions of pages retained by incremental saves, unused form definitions. On a file produced by heavy editing, this can be a substantial saving.
PDF supports incremental updates: when an editor saves a change, it can append the change to the end of the file rather than rewriting it. Do that fifty times and the file contains fifty generations of edits, with only the last one visible. Rewriting collapses that history to the current state. This is where the large savings come from, and it is also worth knowing for privacy — a file saved incrementally may contain earlier versions of text you thought you had deleted.
Before object streams existed, every object in a PDF was written separately with its own header and its own compression. A document with fifty thousand small objects — and a text-heavy report easily has that many, since every glyph position array and every annotation is an object — carried fifty thousand sets of overhead, and each object was too small to compress well on its own. An object stream collects many of those small objects into one container and compresses the container as a unit, which both removes the per-object overhead and gives the compressor enough material to find real patterns in. The cross-reference table can be packed the same way. On a document with many small objects this alone can remove a third of the file, and it is entirely structural — the objects and their contents are unchanged, only the way they are packaged.
Incremental saving has a consequence beyond size. When an editor appends a change rather than rewriting, the previous version of the object is still in the file, merely unreferenced by the current cross-reference table. Delete a paragraph, save, and the paragraph is still in the bytes. Anyone with a text editor or a forensic tool can recover it, and this has produced real disclosures from organisations that thought they had removed something. Rewriting the file constructs a fresh document from the currently referenced objects only, so unreferenced history is not carried over. That is a genuine side benefit of compressing a heavily edited file, though it is not a substitute for proper redaction — content that is still referenced but visually covered remains fully present.
It does not re-encode images, downsample them, subset fonts more aggressively, or drop metadata. Those all reduce size and all change the document. A compressor that silently does them can turn a print-ready file into something that prints badly, and you find out at the printers. Keeping the operation lossless means the output is always safe to use in place of the input.
That is the honest answer for a well-produced file. There was no waste to remove. If the file is still too big, the size is in the images and structural work cannot touch it.
Structural compression will not do it. Re-scan at a lower resolution — 200dpi is plenty for text, and greyscale rather than colour halves it again. If re-scanning is not possible, a tool that downsamples embedded images is what you need, accepting the quality loss.
Occasionally an already-optimised file gains a little from being rewritten with a different structure. Keep the original in that case.
No. The first pass removes what can be removed. A second pass has nothing left to find.
Yes. A signature certifies exact bytes, and rewriting the file changes them. Compress before signing, never after.
A site advertising ninety percent reduction on any PDF is downsampling your images, usually to screen resolution. For a document that will only ever be read on a phone, that is a reasonable trade you should be told about. For anything going to print, it quietly ruins the file. The reductions are real; the cost is real too and often undisclosed.
Acrobat exposes every lever separately — image downsampling per type, font subsetting, transparency flattening, standards conversion — and lets you save the settings. That is the right tool for preparing files professionally at volume. This does one safe subset of that, without a subscription.
Zipping a PDF saves almost nothing, because the contents are already compressed internally. It only helps for sending several files as one attachment.
It depends entirely on the source. Files exported from design tools often carry a lot of unused data and shrink well; a file that is mostly scanned photographs will barely move.
No. This does not re-encode images or drop resolution, so the result looks identical to the original.
The file was already efficient. Real gains on scan-heavy PDFs need image downsampling, which is a different job.