What Actually Shrinks a Bloated PDF

The most common email I get about Toolium's PDF Compress tool is some variation of this: "I uploaded a 30 MB PDF and the compressed output was 27 MB. Is the tool broken?" The answer, every time, is no, the tool is working correctly. The PDF you uploaded is dominated by embedded images, and compressing the document structure - which is what the tool does - barely touches the image data. To shrink that file meaningfully, you would need to resample the images themselves to a lower resolution, which is a fundamentally different operation that I have deliberately not built into the tool.

This post is the explanation of why, plus what you can actually do about big PDFs in practice. The short version: structural compression is fast and lossless and works well on text-heavy documents, image resampling is lossy but the only thing that helps for image-heavy documents, and OCR'd scans are nearly uncompressible regardless of what you throw at them.

What is actually inside a PDF

A PDF file is a container for an object graph. The objects are things like pages, fonts, images, color spaces, drawing commands, metadata, and cross-reference tables that map object IDs to byte offsets. When you ask "why is this PDF so large," the answer depends on which of those objects dominate the byte count.

For a document exported from Word or Pages - mostly text, maybe a few small images and one or two embedded fonts - the byte distribution is usually: fonts 30 to 50 percent, text content 20 to 30 percent, metadata 10 to 20 percent, images 5 to 15 percent. Structural compression (deduplication, object stream consolidation, metadata stripping) can save 20 to 40 percent on this kind of file because there is genuine redundancy to remove.

For a document with embedded photos - a scanned contract, a report with charts and screenshots - the distribution is dominated by image bytes, often 80 to 95 percent of the total file size. The fonts and metadata are still there but they are noise against the image data. Structural compression saves maybe 5 percent, because the images themselves are already compressed and not much else is taking space.

For a scanned document with no embedded text layer - just images of pages, one image per page - it is 100 percent image bytes. Nothing structural to compress. The only way to make the file smaller is to resample the images to a lower resolution or recompress them at a lower JPEG quality.

What the Toolium compressor actually does

The PDF Compress tool performs three operations on the document, all lossless from the visual standpoint:

Object stream consolidation. PDF allows multiple small objects to be packed into a single compressed stream. Documents produced by older tools often have hundreds of separate small objects when they could be one stream. Consolidation can save 5 to 15 percent on those files.
Deduplication. Identical objects (a font that got embedded twice, an image that appears on two pages) get merged into a single reference. This is the biggest win for documents produced by copy-paste workflows where the same logo appears on every page.
Metadata stripping. The XMP metadata block, document history, annotation log, and embedded thumbnails get removed. Most of these are not useful for the recipient and can add hundreds of KB to a document.

For text-heavy documents these three operations combined typically achieve 20 to 40 percent size reduction. For image-heavy documents they achieve 0 to 10 percent. The tool reports the percentage and the original-vs-output byte counts so you can see what you got.

What the tool does not do, and why

The tool does not resample images. If your PDF has a photo embedded at 4000x3000 pixels and the visual display size is 800x600, the natural compression move would be to downsample the embedded image to something closer to the display size, then re-encode at a lower JPEG quality. This is what desktop tools like Acrobat Pro do when you pick "Reduce File Size" - and it's where most of their compression actually comes from.

I have not built this into the browser-based version for two reasons. First, the user trade-off is hard to expose well. Resampling is lossy; once you reduce a 4000-pixel image to 800 pixels, the original detail is gone. If you compress, then later want to print at high resolution, you cannot. Acrobat handles this by offering presets ("for screen viewing," "for print at 300 dpi") and warnings; I have not figured out a clean way to do that in the browser without making the interface much more complicated. Second, doing the resampling well requires re-rendering the page content, which pdf-lib in the browser does not support cleanly. The "easy" implementation produces visibly worse output than Acrobat's, and I would rather not ship it than ship a poor version.

If you have an image-heavy PDF and structural compression did not help, the realistic options are:

Adobe Acrobat (paid) or Adobe Acrobat online (free trial). Their image resampling is the industry baseline.
PDFsam Visual (paid, but cheaper than Acrobat). Good image compression options.
Ghostscript on the command line (free). Powerful but the learning curve is steep. The command you usually want is: gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dPDFSETTINGS=/ebook -dNOPAUSE -dQUIET -dBATCH -sOutputFile=output.pdf input.pdf. The /ebook preset targets 150 DPI; /screen targets 72 DPI for emailing; /printer targets 300 DPI.
Extract the images, downsample with a separate tool, rebuild the PDF. Tedious but works for one-off documents.

The scanned-document problem

The hardest case is a PDF that is purely scanned images of paper, no text layer. These files are usually large (each page is a photo) and almost completely uncompressible by structural tools. The byte size is dominated by the per-page image bytes.

The ways to actually make these smaller:

Lower the scan DPI at the source. Scanning at 600 DPI gives a 4x file size of scanning at 300 DPI. For most documents 300 is plenty.
Convert to grayscale if it does not need color. A grayscale image is roughly one-third the size of a color image at the same dimensions.
Re-encode the images at lower JPEG quality. Acrobat or Ghostscript can do this.
Run OCR and discard the original images. If the document is text content, OCR produces a searchable text-only PDF that is dramatically smaller. The trade-off is that any images, signatures, or layout details get lost.

For sharing a scanned contract via email when you cannot get the file under the attachment limit, the practical move is often to convert to a PDF with grayscale images at lower quality, accept that it looks slightly worse, and send. Toolium does not do this conversion; it is on the list of things to maybe build if I figure out the trade-off interface.

Privacy and the absent server

Same as every other Toolium tool. The compression happens in your browser using pdf-lib. Your file is read from a local File object that the browser hands the page; no upload is involved. If you are compressing a contract or a tax return, the contents do not leave your computer. Open the network tab if you want to verify.

The honest summary

If your PDF is text-heavy and the file is much larger than it should be, the Toolium compressor is probably exactly what you want. Drop it in, get 20 to 40 percent smaller in a couple of seconds, no quality loss. If your PDF is image-heavy and the structural compression came back near zero, you need a tool that resamples images, and the Toolium compressor is not the right tool for that job. The methodology page covers the broader pattern of which Toolium tools are good for which jobs and which intentionally are not.