How to reduce a PDF file size (without destroying it)

PDF size is almost never about the text. Text in a PDF is tiny — a hundred pages of plain prose compresses to a few hundred kilobytes — so when a file feels heavy, the bytes are hiding somewhere specific: embedded images, scanned page rasters, embedded fonts, or leftover baggage from how the file was produced. Finding which one applies to your file turns "make it smaller" from a guessing game into a two-minute diagnosis.

The four usual suspects, in order of how often they dominate. First, raster images: photos, screenshots, and exported graphics, stored at far higher resolution than anyone will ever view them — a 600 DPI scan of a letter-size page is a 50-megapixel photograph of a piece of paper. Second, scanned pages as a special case: every page of a scan is one full-page image, so a 30-page scan at camera quality routinely lands between 15 and 60 MB. Third, embedded fonts: full font programs embedded "just in case" can add megabytes even when two typefaces are used. Fourth, production artifacts: transparency layers, embedded files, editing histories, and duplicate object streams left by some exporters.

Two questions separate the right fix from wasted effort. Question one: is this a born-digital document or a scan? Open the file and try to select text. If characters highlight, the text is real — the file is born-digital, and image downsampling is your main lever if images exist at all. If nothing selects and every page looks like a photograph of paper, it is a scan, and the page rasters are essentially the entire file size.

Question two: which pages earn their bytes? A 60-page PDF that recipients actually read end-to-end is one problem; a 60-page PDF where everyone only ever needs pages 12–17 is a different, easier one. Page-level surgery — extracting the range people need and sharing that — often cuts 90% of the bytes with zero quality loss, because nothing is recompressed; pages are simply separated. It is the least glamorous fix in this guide and frequently the best one, which is exactly why the PDF workspace has dedicated tools for it.

Work down this list and stop as soon as the file is small enough. Each step preserves more fidelity than the one below it.

1. Remove pages you do not need. Extract the chapter, the signature page, or the relevant section with a split tool and share that instead. No recompression, no quality decision, pure byte removal.
2. Re-export from the source document. If you still hold the original (Word, Google Docs, InDesign, LaTeX), export again with "reduce size" / "standard" settings and images downsampled to 150–200 DPI for screen use. The source always produces a better result than post-processing a PDF.
3. Downsample the embedded images. Tools like Ghostscript (free), Acrobat's save-as-other reduction, or Preview on macOS can resample every embedded image to a target DPI. 150 DPI is invisible on screens; 300 DPI only matters if the document will be printed.
4. Strip baggage. Remove embedded attachments, unused color profiles, editing bookmarks, and duplicate layers. Acrobat's "remove hidden metadata" and Ghostscript's cleaner presets handle this; the savings are modest unless the file came from a heavy exporter.
5. Flatten and finalize only as a last step. Flattening transparency and converting everything to final form can shrink pathological files, but it sacrifices editability and can rasterize vector content — do it to files you will only ever distribute, never to masters.

The page-removal path deserves concrete detail because it is the fix anyone can do in a browser with no software. Open the PDF workspace, load the file, and the page thumbnails render locally — the file never leaves your machine, which also matters when the oversized PDF is a contract, a medical report, or anything you would not upload to a free converter site.

From the thumbnails you have three moves. Split by range: extract pages 12–17 into their own file and send that. Split into chunks: break a 200-page compilation into per-chapter files so each recipient downloads only their part. Delete-and-merge: remove the three appendix pages nobody reads from the full document and export the remainder as a single clean PDF. All three preserve the original page objects exactly — images are copied, not re-encoded, and text stays vector and searchable. That preservation is the point: the extracted 6-page file is not a re-compressed approximation of the original, it is the original pages, just fewer of them.

• Extract a range → the 5 pages people need, at original quality
• Chunk a long file → per-section PDFs, each a fraction of the weight
• Delete filler pages → merge the keepers back into one document
• Everything runs locally — oversized files are often the sensitive ones

The classic mistake is re-saving a PDF through a PDF again and again, each pass re-encoding images at lower quality while adding nothing. If a file is already compressed, a second lossy pass mostly destroys it: text edges soften, screenshots develop mosquito noise around letters, and the size savings after the first pass are small anyway. Compress once, from the highest-quality version you have, and keep that master.

The second mistake is sacrificing searchability to hit a size target. Converting a text document to images (or keeping a scan without OCR) makes the file smaller only by making its content invisible to search, copy-paste, and screen readers. If the document contains real text, keep it as text — the correct trade is almost always smaller images, never dead text. And third: do not trust size alone as the quality check. A 2 MB PDF that lost its diagram labels is worse than a 4 MB PDF that kept them. Open the result, zoom to 100% on the pages that matter, and confirm nothing you needed was traded away.

Put together, the workflow for an oversized PDF is short. Open it and try to select text: if the pages you need are a small range, extract that range and stop — you are done in a minute with a perfect-quality result. If you need the whole document and it is a scan, the fix lives at the scanner or in an OCR/downsampling pipeline, not in page surgery. If it is born-digital with fat images, re-export from the source if you have it; otherwise downsample embedded images once with a proper tool.

Then verify like a recipient would: open the result on a different device, check the pages that carry the load — the chart, the screenshot, the signature block — at full zoom, confirm text still selects, and only then upload or email it. Most "how do I shrink this PDF" problems end at step one with a split; the rest of the ladder exists for the files that genuinely need it. And when the real problem is that the file needs to be both complete and small, the honest answer is image downsampling done once, carefully, rather than another round of hopeful re-saves.