Reducing a PDF’s file size effectively starts with understanding what’s actually taking up the space — the right approach is completely different for a scanned document than for a typed report, and applying the wrong one either does nothing or damages content you didn’t need to touch.
Find out what’s actually large first
Before compressing anything, it’s worth knowing which of two very different situations you’re in:
It’s mostly (or entirely) scanned/photographed pages. Each page is effectively an image file wrapped in a PDF container. This is where compression has dramatic effect — 80-95% size reduction is completely normal, because you’re re-encoding real image data more efficiently.
It’s a native document (exported from a word processor) with some embedded images. The text itself takes almost no space. If the file is unexpectedly large, it’s the embedded photos, charts, or graphics doing it, and compression will target those specifically — the text-only pages won’t shrink further because there’s nothing to shrink.
The two knobs that matter for scanned pages: quality and DPI
JPEG quality of the page images works exactly like compressing a standalone photo — lower quality means smaller file size and more visible artifacts, particularly around text edges (where you’ll see the same ringing/blocking that affects an over-compressed photo).
DPI (resolution) is the second, often more impactful lever. Scanners frequently default to 300, 400, or even 600 DPI, which is far more resolution than most documents need to remain fully readable. As a practical guide: 300 DPI is standard for archival-quality or documents that might be reprinted, 200 DPI is fine for typical reading and most upload requirements, and 150 DPI is the floor before small text noticeably softens. Downsampling from 400+ DPI to 200 DPI alone, before touching JPEG quality at all, often accounts for the majority of the size reduction in an over-scanned document.
Why native (typed) PDFs barely shrink
If you compress a PDF exported directly from Word or Google Docs and see almost no size reduction, that’s expected, not a failure of the tool. Text stored as font glyphs and positioning data is already extremely compact — there’s no image data for a compressor to re-encode. If such a document is large, it’s virtually always because of embedded images (photos, high-res charts, screenshots pasted into the document), and those are what a compressor will actually act on.
What stays untouched regardless of compression level
A real text layer — the kind you can select, search, and copy from — is stored completely separately from image data in the PDF’s internal structure. Compression tools that target image data don’t touch it at all, so text integrity, searchability, and selectability are preserved no matter how aggressively you compress the embedded images. This is the key distinction from compressing a scanned document, where the “text” is just pixels and is directly affected by the same quality trade-offs as a photo.
A practical checklist
- Check whether your PDF has real text (try selecting some) or is a scan.
- For scans: check the current DPI if you can (often in scanner settings or file properties) — if it’s above 300, downsampling alone will help a lot.
- Compress with a target size in mind, and always zoom into a representative page of small text afterward before relying on the result for anything important.
- For native documents that are still large, look for what images are embedded — those are the actual target, not the text.
Frequently asked questions
- What's usually taking up all the space in a large PDF?
- In the vast majority of cases, it's embedded images — scanned pages, photos, or high-resolution charts and diagrams. Text itself, stored as font glyphs and coordinates rather than pixels, is extremely compact even across hundreds of pages. If a PDF is unexpectedly large, the first thing to check is whether it contains scanned or photographic pages, or embedded images, since that's almost always where the size is coming from.
- What DPI should scanned pages actually be?
- 150 DPI is the practical floor for readable text in a scanned document — below that, small fonts start to blur noticeably. 200-300 DPI is standard for documents that need to look sharp or might be printed again. If your scanner defaults to 400-600 DPI (common on flatbed scanners set for photo scanning), you're likely capturing far more resolution than the document needs, and downsampling to 200-300 DPI during compression can cut file size dramatically with no visible loss for a text document.
- Does compressing a PDF remove the ability to search or select text?
- Only if the PDF didn't have real selectable text to begin with. A native PDF (exported from Word, Google Docs, etc.) stores text as actual text, separate from any images, and compression that targets image data leaves it completely untouched — still searchable and selectable at any compression level. A scanned PDF without OCR has no real text layer at all; what looks like text is pixels in an image, and 'compressing the text' isn't actually possible or meaningful — compression there is purely an image-quality trade-off.
- Can I compress a PDF without changing its page count or layout?
- Yes — standard compression re-encodes the images and internal data structures within each page without altering the page count, page order, or layout. If a compression result looks visually different in layout (not just image quality), something else is going on, like the tool re-flowing or re-generating the document rather than just compressing it.
- My PDF has both text and large images (a report with embedded photos) — how does compression handle that?
- A proper PDF compressor identifies and processes each embedded image individually — re-encoding photos and downsampling their resolution as needed — while leaving the surrounding text layer, fonts, and document structure untouched. The result is a file where the text stays crisp at any compression level and only the size of the embedded images actually shrinks.