Why is my PDF so large? A look inside the file

A one-page Word export is 40 KB. A one-page scan of the same letter is 4 MB — a hundred times bigger. Nothing about the information on the page changed; what changed is how it’s stored. Understanding that difference is the whole game of PDF compression, and it explains why some PDFs shrink by 90% while others won’t budge.

The size hierarchy inside a PDF

Roughly, from featherweight to heavyweight:

Text and vector graphics are nearly free. A page of text is a few kilobytes: character codes, positions, and a reference to a font. Lines, tables, logos drawn as shapes — all similarly tiny. This is why a 300-page contract exported from a word processor can be smaller than a single phone photo.

Fonts cost a little. An embedded font adds tens to hundreds of kilobytes. Well-behaved exporters embed a subset — just the characters used. Badly behaved ones embed entire font families, repeatedly. In text-only documents that are mysteriously large, fonts are the usual suspect.

Images cost everything else. In practice, when a PDF is big, it’s images — and it’s rarely close. A scan is an image of the whole page. A report with phone photos carries each photo at whatever size the camera produced.

The DPI math that explains your scan

An image’s stored size is pixels × pixels × color depth, tamed by compression. A US-letter page scanned at 300 DPI in color is roughly 2550 × 3300 pixels — about 8.4 million pixels, ~25 MB uncompressed. JPEG compression brings that to 1–3 MB per page depending on quality and content. Multiply by 40 pages and you have a 60–100 MB file from one trip through the scanner.

The same page at 200 DPI is ~4.7 million fewer pixels (3.7 M vs 8.4 M) — files drop by more than half — and on screen the difference is barely perceptible, because typical displays show documents at 100–150 effective DPI anyway. At 150 DPI grayscale, that letter page can live comfortably under 200 KB. This is why scanner settings matter more than any after-the-fact tool: a document born at 600 DPI color is carrying 16× the pixels of one born at 150 DPI.

Phone photos have the same problem in different clothes: a modern phone produces 4,000+ pixel wide images, 3–6 MB each. Drop four into a one-page flyer and the flyer weighs 20 MB, of which 19.9 MB is resolution nobody will ever see.

The smaller offenders

• Metadata and previews. Author, title, editing history, XMP records, sometimes embedded page thumbnails. Usually tens of KB — trivial for size, non-trivial for privacy.
• Incremental saves. Some editors append changes to the end of the file rather than rewriting it, so the PDF accumulates its own history — including “deleted” content. A file edited many times this way can be far larger than its content justifies. A clean rebuild discards the archaeology.
• Duplicated resources. Merge tools of varying quality can embed the same font or image once per source document.

What honest compression does about each

Knowing the anatomy, compression writes itself:

1. Re-encode oversized images at a sane resolution. This is where the real savings live — downscaling a 4,000-pixel photo to document resolution and re-encoding routinely cuts 60–85% of a scan-heavy file. It’s also where the quality trade-off lives, which is why a trustworthy tool makes the level explicit (light ≈ print quality, balanced ≈ screen quality, strong ≈ smallest readable) instead of promising magic.
2. Strip metadata and leftover structure. Small wins, always safe.
3. Rebuild the file compactly. Rewriting discards incremental-save history and stores internal structures in compressed form. On a file with a long editing history this alone can matter; on a clean file it saves a few percent.

Why some PDFs refuse to shrink

Run the anatomy backwards and the stubborn cases explain themselves:

• Text-only documents have nothing heavy to remove. A 300 KB text PDF is already near its floor — anyone promising to halve it is rasterizing your text (turning it into images), which makes it worse: bigger or blurrier, and no longer searchable.
• Already-compressed scans. Re-compressing a JPEG that was already saved at low quality mostly adds artifacts. There’s little left to give.
• Vector-heavy CAD drawings and maps are thousands of tiny drawing operations — not images, so image re-encoding doesn’t touch them, and their content genuinely is that detailed.

A tool that can’t shrink your file meaningfully should say so and keep your original. (Ours does — a “compressed” file that’s 1% smaller helps nobody.)

If the file is still too big

When a hard limit — an e-filing cap, a portal’s upload maximum, an email attachment ceiling — exceeds what honest compression achieves, change the shape of the problem instead of the quality:

• Split the document and send parts. Universally accepted, zero quality cost.
• Extract only the pages the recipient needs — often the real answer; nobody wanted the 60-page appendix anyway.
• Re-scan at sensible settings if you control the scanner: 200 DPI grayscale for text documents is the librarians’ sweet spot, and it prevents the problem at birth.