Inside a PDF: why files get huge and what compression actually changes

A 40 MB PDF is almost never 40 MB of text. The bulk is almost always pixel data that was never meant to travel as email attachments. Understanding the actual structure makes the “why is it so big?” and “why did compressing it only save 8 %?” questions make sense.

The PDF object graph (extremely simplified)

A PDF is a collection of numbered objects (numbers, strings, arrays, dictionaries, streams) plus a cross-reference table (xref) that tells a reader where each object lives in the file. Pages are dictionaries that point to content streams, resources (fonts, images, color spaces), and annotations.

Nothing is inherently “a page of pixels”. A page can contain:

• A content stream of vector drawing commands (tiny)
• References to embedded fonts (small to medium)
• Image XObjects that are full raster bitmaps (the megabytes)

When someone exports “Save as PDF” from Word or exports slides from PowerPoint, every placed photo usually becomes its own high-resolution image XObject, even if it is displayed at 1/4 size on the slide.

Where the megabytes actually live

1. Scanned pages. Each page is a photograph. A 300 DPI letter-size grayscale scan is already ~8–9 MB uncompressed; color is 3× that. Ten pages = 250 MB before any compression.

2. Embedded photos at native resolution. A 24 MP camera JPEG dropped straight into InDesign stays 24 MP inside the PDF even when printed at 3 inches wide.

3. Duplicate images and fonts. Some generators embed the same logo or font subset on every page instead of reusing one object.

4. Incremental updates / “save” bloat. Many PDF editors never rewrite the file; they append new objects and a new xref. After a few “save” cycles you can have three copies of every image and page inside one file.

Text, even a 400-page novel, is usually under 1 MB because it is stored as compact character codes plus font descriptors.

What “compress PDF” tools actually do

There are two very different operations hiding under the same marketing label:

Image recompression (the big win)
Re-encode every image XObject with a lower JPEG quality or downscale it to the resolution it is actually displayed at. Text and vector content are left alone. This is what LocalTools’ PDF compressor does on normal pages.

Full restructure / linearization / garbage collection
Rewrite the entire file, deduplicate objects, remove incremental-update junk, reorder for fast web loading, possibly flatten forms or drop metadata. This can be dramatic on editor-bloated files but does almost nothing on a clean export that only contained big images.

If a tool claims “compressed your 35 MB PDF to 34 MB”, it probably did the second thing on a file whose real problem was image data.

What gets lost or changed

• Selectable text survives when you only touch images. A text PDF stays searchable.
• Scanned pages stay images. You cannot turn a photograph of text into real selectable text without OCR (which this site does not perform).
• Form fields and JavaScript can be damaged by aggressive optimizers. Compress before you fill forms if you need them to remain interactive.
• Bookmarks / outlines / layers are usually preserved by image-only compressors but may be stripped by full rewriters.
• Print fidelity. 150 DPI is fine for screen and most email; 300 DPI is safer for anything going to a print shop.

Why splitting sometimes beats compressing

If you only need pages 7–12 of a 180-page scan, splitting first and then (optionally) compressing the fragment is both smaller and faster than compressing the whole monster. Ten high-res page images are often more manageable than one giant file containing 180 of them.

How to keep future PDFs small at the source

• In Word/PowerPoint: reduce image resolution on export or compress pictures inside the document before exporting.
• In design tools: link rather than embed, or downscale placed images to final print size before export.
• For scanned contracts: scan at 200–300 DPI grayscale when possible instead of 600 DPI color.
• For photo albums: build the PDF from already-compressed images using a tool that lets you choose the quality up front (Images → PDF with compression controls).

A note on “online PDF compressors”

The documents people most want to shrink — contracts, medical records, tax returns, ID scans — are exactly the ones that should never be uploaded to an unknown server. Every technique described above can be performed locally because the heavy lifting is just re-encoding image streams and rewriting a modest object graph. That is why the tools on this site never require a network round-trip for the actual work.

Understanding the structure also explains the results you see: a 2 % reduction usually means “we only deduplicated objects”; a 70 % reduction almost always means “we re-encoded the photographs”.