Why your PDF is so much bigger than it needs to be.
A ten-page contract has no business weighing forty megabytes — and yet here we are, failing the upload-size limit again. PDF bloat isn't mysterious: nearly all of it lives in a handful of places, and most of those places compress dramatically without changing what anyone sees. Here's where the weight actually is, and what a compressor can and can't safely do about it.
A PDF is a container: text, vector drawing commands, images, fonts, and metadata packed into one file. None of those parts is inherently heavy — the format compresses its internals — so when a PDF is huge, it's because something specific inside it is huge. Finding the something is the whole game.
Two kinds of PDF, two size stories.
Digital-born PDFs — exported from Word, Google Docs, LaTeX, a design tool — store text as text: character codes plus font references plus positioning. That's astonishingly compact; a hundred pages of pure text costs less than a single phone photo. When a digital-born PDF is fat, the culprit is almost always an embedded image or font, not the document itself.
Scanned PDFs are a different species. A scanner doesn't produce text — it produces a photograph of the page, and the PDF is a stack of full-page images with no text in it at all (unless OCR added an invisible layer). Every size intuition changes: the "document" is really an image album wearing a PDF coat, and its weight is governed by image math — resolution × color depth × compression — exactly the territory of the image compression guide.
Scans: a photo of every page.
The arithmetic explains most forty-megabyte contracts. An A4 page scanned at 300 DPI is roughly 2500 × 3500 pixels; stored as full-color JPEG at high quality, each page can easily run to multiple megabytes. Ten pages of that and you've built a small photo album to convey what is, informationally, a few kilobytes of words.
The big levers, in order of impact:
Color mode. A black-and-white document scanned "in color" carries three channels of paper texture and lamp tint. Grayscale cuts it; true black-and-white (1-bit) formats built for documents — CCITT Group 4 or JBIG2 — cut it dramatically, which is how fax machines moved pages over phone lines in the 1980s.
Resolution. 300 DPI is the archival/OCR standard; for reading on screens, 150 DPI usually looks identical at normal zoom and is a quarter of the pixels. Halving DPI quarters the raw data.
Compression choice. Some scanner drivers store pages with feeble or no image compression. Re-encoding those pages as proper JPEG (photos) or CCITT/JBIG2 (text) is where "compress PDF" tools earn their headline numbers.
Fonts: shipping the whole typeface.
Digital-born PDFs embed fonts so the document renders identically everywhere — the right call. The size question is how much of each font gets embedded. A subset embeds only the glyphs the document actually uses (you'll see names like ABCDEF+Helvetica inside the file); a full embed ships every glyph in the typeface — potentially thousands, especially for CJK fonts, where a single fully-embedded font can outweigh the rest of the document combined. Office exporters usually subset by default, but "editable PDF" settings and some print workflows force full embeds. A document using several weights of several families, fully embedded, is fat before it says a word.
Dead weight: duplicates and leftovers.
Three quieter sources round out the taxonomy:
Duplicated resources. A logo placed on every page, or the same image pasted repeatedly, should be stored once and referenced everywhere — but plenty of generators store a fresh copy per page. Fifty pages, fifty logos.
Incremental-save leftovers. PDF supports incremental updates: some editors append changes to the end of the file rather than rewriting it, leaving every superseded version of every edited object inside forever. A heavily-edited document can carry its own history like sediment. (This has burned people the other way, too — "deleted" content that was still in the file.)
Everything else. Embedded thumbnails, print-oriented ICC color profiles, XML metadata, file attachments, form scaffolding. Individually small, collectively real — and almost always removable for a screen-reading copy.
What a compressor actually does.
Given the taxonomy, a "compress PDF" tool is less magical than it sounds. It walks the file and applies, roughly in order of payoff: re-encode and downsample images (the dominant win on scans and image-heavy decks), deduplicate resources so repeated objects are stored once, rewrite the file cleanly — dropping incremental-save sediment, dead objects, thumbnails, and optional metadata — and compress the structure itself (object and cross-reference streams, a PDF 1.5+ feature older generators skip). Font subsetting is the one big lever most quick tools don't pull, because safely re-subsetting an embedded font is genuinely tricky.
What's safe and what costs quality.
| Operation | Lossless? | Risk |
|---|---|---|
| Structure rewrite, dedupe, stream compression | Yes | None visible — same pixels, same text |
| Stripping metadata / thumbnails | Yes* | *Lost if you needed the metadata |
| Image re-encoding / downsampling | No | Softness at high zoom; artifacts if aggressive |
| Color → grayscale / 1-bit | No | Obvious — only right for B&W source docs |
The practical rule: decide what the copy is for. An email-able review copy tolerates aggressive image compression; the version you sign, archive, or print deserves the lossless-only treatment. And if a compressor promises huge savings "with no quality loss" on a scan-heavy file, it's re-encoding images and hoping you don't zoom in — informed is fine, surprised is not.
Takeaways.
The thing to remember: PDF weight lives in specific places — page-photo scans first, embedded images and unsubset fonts second, duplicates and incremental-save sediment third. Structure cleanup is free; image re-encoding trades quality for size. Scanned documents are image files in a trench coat, so image rules apply.
The forty-megabyte contract isn't a fact of nature; it's a stack of over-resolved color photographs of black text on white paper. Knowing that turns "compress PDF" from a magic button into an informed decision about which lever you're pulling.
Compress PDFs in your browser.
The PDF Compressor re-encodes and rebuilds your file entirely client-side — the document never uploads anywhere, which matters precisely for the contracts and records most likely to need shrinking.
Open the PDF Compressor
Made with love by a very serious person pretending not to be. Tooly McToolface is a workshop of free, client-side web tools. The image math underneath every scan lives in the image compression guide, and why your SVGs are 3× too big is the same detective story for vector files.