PDF Compression Methodology
A useful first question is what makes this PDF large. Content, existing encoding and the selected method all affect the result. This methodology explains where PDF size comes from and the trade-offs in down-sampling, JPEG quantization, grayscale and de-duplication, then offers a decision tree. Treat examples as context, not predictions of a reachable minimum. Processing is local; files are never uploaded.
Where does a PDF's size actually come from?
To compress something, you first have to know what you're compressing. A PDF's size breaks down into roughly four parts: page images (the bitmap data of scans, photos and illustrations), vectors and text (glyphs, paths, table rules), embedded fonts (full or subsetted font files), and structural overhead (metadata, bookmarks, annotations, thumbnail caches, duplicate objects). For nearly every 'too big to upload' file, the first part — page images — is over 80% of the size.
That's why the same 10 pages can be 300KB as a Word export and 30MB as a phone-photographed contract: the former is vector text, the latter is ten multi-megapixel color photos. The first step in judging how small a file can get is always the same question — is its size mostly images, or mostly text?
| Size source | Typical share | Headroom | Technique |
|---|---|---|---|
| Page images (scans / photos) | ~80–98% of image PDFs | Very large | Down-sample + JPEG + grayscale |
| Vectors & text | Bulk of a text PDF | Tiny | Font subsetting, de-dup |
| Embedded fonts | Tens of KB to a few MB | Medium (subset) | Subset / drop unused glyphs |
| Structural overhead | Usually < 5% | Small (lossless) | Strip redundant objects |
The four techniques — how much does each save?
'Compressing a PDF' is really a mix of independent techniques. Understanding each one's cost and payoff is what explains why some files shrink instantly and others won't budge.
The first three can trade image information for size; lossless optimization removes redundancy without discarding image detail. Savings vary by file, and none guarantees an exact size or an upload limit.
- Image down-sampling (lower DPI): dropping a 600DPI scan to 150DPI cuts pixel count to ~1/16 — the single biggest saving. The cost is softness when zoomed in, but 150–200DPI is plenty for screen reading and most reviews.
- JPEG quantization (higher ratio): a more aggressive JPEG quality on page images shrinks size fast. The cost is faint 'mosquito' noise around text edges, visible below roughly quality 50.
- Grayscale / black-and-white: dropping color may reduce size when color is unnecessary. Savings depend on the source and encoding; check that color carries no required information before discarding it.
- Lossless optimization removes redundant data without discarding image detail. Savings depend on the file and can be negligible; there is no fixed percentage or target guarantee.
How small can different content get? A reference table
Treat the table as illustrative ranges, not a promise or measured minimum for your file. Page count, encoding, fine detail and method can substantially change the outcome. Check actual output bytes and every page rather than using a table row to predict success.
| Content type | Typical size before | Compresses to | ≤200KB? |
|---|---|---|---|
| B&W text scan (200–300DPI) | 0.5–2 MB / page | 20–80 KB / page | Usually yes |
| Color document scan (300DPI) | 1–4 MB / page | 80–300 KB / page | Single page often; multi-page hard |
| Phone photo → PDF | 2–6 MB / page | 100–400 KB / page | Needs lower DPI + grayscale |
| Text PDF (Word export) | Already small | Almost no headroom | Already fits — no need |
| Image-heavy brochure / portfolio | 5–20 MB+ | 1–5 MB | Practically impossible |
The decision tree: which path for the file in your hands?
Here's the methodology distilled into an executable judgment. Start from 'what kind of file is this', follow the branch, and you'll land on the least-effort, least-blurry strategy.
- Pure text (Word/Docs export, no scanned images)Try 'Keep selectable text' if compression is needed. Savings may be small, and an already small PDF may fit the limit without processing.
- Black-and-white text scanStart with 'Keep selectable text'. If you choose 'Compress as images', consider grayscale only when color is unnecessary, and inspect small text and output bytes.
- Color scan / photo, one or a few pagesSet a target within the upload limit and start with 'Keep selectable text'. If choosing image compression, review the loss of selectable text and possible detail loss; grayscale is optional when color is unnecessary.
- Dozens of pages, needs to be a few hundred KBRemove unnecessary pages only if submission rules allow, then try compression and review the result. Page count affects size but does not establish a fixed minimum.
- Image-heavy brochure / portfolioCompress the source images then rebuild the PDF, or accept a larger target (e.g. ≤10MB); over-compressing destroys the artwork.
Why a file sometimes 'won't compress'
A file may shrink little because it is already compressed, because the method preserves its content, or because processing encountered a limitation. Review per-file status and actual output. An above-target result does not establish a physical minimum or mean that every possible method was tried.
- Already compressed images may offer little reduction without losing more detail. Try a looser target or a better source export.
- Many scanned pages can make a small target difficult. If allowed, reduce pages or use separate submissions; there is no fixed byte minimum per page.
- The target is too aggressive: crushing a crisp color scan to 30KB makes it unusable. Try 200KB, then tighten in steps.
- It's actually a text PDF: already small with almost no headroom — 'won't shrink' is normal, because it never needed compressing.
Frequently asked questions
Why is a scan dozens of times bigger than a Word export at the same page count?
Because a scan is a high-resolution bitmap per page (image data), while a Word export is vector text that barely adds size. The whole gap comes from 'images vs. text', which is also why the scan compresses dramatically and the text PDF has almost no headroom.
Which matters more for size — lower DPI or higher JPEG ratio?
Halving DPI leaves one quarter as many pixels, but encoded size does not necessarily fall by the same ratio. JPEG quality also affects each image differently. With 'Compress as images', inspect the actual output rather than assuming a setting guarantees a target.
Can lossless compression get me to 200KB?
It depends on the original file. Lossless optimization has no fixed savings percentage and may barely change an optimized PDF. Start with 'Keep selectable text'; choose image compression only if you accept its losses, and check whether the output fits.
How do I tell whether my file can reach the target?
The table offers examples, not a reliable prediction for your file. Start with 'Keep selectable text', request a target that fits the receiving site's byte limit, and inspect the actual output. Remaining above target does not prove that a smaller file is impossible.
Updated · compress cat team