A PDF that should be a few pages long sometimes arrives at forty megabytes, refuses to send, and leaves everyone staring at the same question: what is actually inside it? The answer is rarely the text. Text is tiny. A whole novel's worth of words fits in a fraction of a megabyte. When a PDF balloons, the bulk almost always comes from one of three sources: images stored at full size, fonts embedded in full, or pages that are scans rather than text. Finding which one applies to your file tells you which compression approach will work, because the three problems respond to different fixes.
Compress PDF offers two modes, and the choice between them depends on the diagnosis below. The lossless re-save keeps the text selectable and shrinks what it can without rebuilding pages. The smallest-size rebuild turns pages into images, which can shrink much further but gives up selectable text. Knowing what is making your file large lets you pick the mode that solves your problem without sacrificing something you need.
Culprit one: images at full size
The most common cause is photographs embedded at the resolution they came out of a camera or a scanner, even though they are displayed at a fraction of that size on the page. A photo that appears as a small illustration may still be stored at several thousand pixels wide. Multiply that by twenty photos in a report, and the file is suddenly tens of megabytes, most of it invisible to the reader.
You can often spot this culprit from the document's history. A report assembled from phone photos, a catalogue built from product shots, or a presentation exported with high-resolution images all point the same way. The fix is to reduce the image data, either by compressing the PDF's smallest-size rebuild or, before the PDF stage, by optimising the images themselves. Image Optimizer handles that earlier step for image files, resizing and compressing them in a batch before they ever reach a PDF. Either way, the principle is the same: the stored image only needs to be as detailed as the page it is printed or viewed at, and anything beyond that is dead weight.
Culprit two: embedded fonts
Fonts are the quieter culprit. When a PDF embeds a font so the document looks the same on any machine, it can embed the whole font family: regular, bold, italic, and every character set, even if the document uses a handful of characters. Several embedded fonts across a long document add up, sometimes to several megabytes. This is more common in documents produced by design software or exported from presentation tools, where font embedding is thorough by default.
Font bulk is harder to see and harder to fix by hand, which is why a re-save helps: the lossless mode rewrites the file's structure and drops some of the redundant data that accumulates through repeated edits and exports. It will not rewrite the fonts themselves, so a file whose bulk is mostly fonts may shrink only modestly in lossless mode. That modest result is itself diagnostic information. If a lossless pass barely moves the size, the bulk is probably in the fonts or in image data that the re-save preserves by design, and the smallest-size rebuild becomes the honest next step, with its trade-off stated openly.
Culprit three: scanned pages
A scanned document is a stack of photographs of pages. Each page is an image, often captured at high resolution, with no text at all unless OCR has added a layer. A fifty-page scan is therefore fifty photographs, and fifty photographs are heavy. This is why scanned files are so often the ones that bounce back from an inbox: they carry image weight on every single page, not just on the pages that contain pictures.
Scanned bulk responds well to the smallest-size rebuild, because rebuilding pages as images at a sensible size attacks exactly the problem: oversized page images. The trade-off matters more here than anywhere else, though. If the scan has already been OCR-processed so its text is searchable, rebuilding pages as images can remove that text layer, and the result is no longer searchable. Check before you compress a scanned file whether you rely on searching or copying its text. If you do, prefer the lossless mode, accept the smaller saving, and consider whether the document needs all its pages at all.
Worked example: a fictional community report
The example is fictional: an invented organisation, invented figures, and a made-up file size, used to show the diagnosis in action. Imagine the fictional Riverside Residents Group, contact via hello@example.org, produces a 24-page annual report. The file comes out at 38 MB, and the group's email provider refuses it. The organiser opens the file and works through the three culprits. The report contains photographs from community events, so images are a suspect. It was laid out in design software, so fonts are possible. But most pages are typed text, not scans, which rules out the third culprit for most of the file.
She runs the lossless re-save first. The file drops from 38 MB to 31 MB: a real saving, but not enough. That result points at image bulk preserved by the lossless mode, so she tries the smallest-size rebuild on a copy, not the original, and the file falls to about 6 MB. She checks the result page by page: the photographs are slightly softer but still clear at normal reading size, and the text, which was selectable in the original, is now part of the page images. For a report that will be read and printed rather than searched, that trade is acceptable, and she sends the smaller file. For the archived copy, she keeps the original, so the selectable text is not lost for good.
The lesson is the order of operations: diagnose first, try the gentler mode first, check the result, and only then accept the stronger trade-off. Compressing blindly, especially on the only copy of a file, is how searchable text gets lost for no reason.
Honest limitations
Compression cannot create quality that is not there, and it cannot recover text that a rebuild turns into images. The lossless mode preserves text but may not shrink enough for a strict size limit. The smallest mode shrinks further but gives up selectable, searchable text. Neither mode can fix a file whose bulk comes from content you actually need at full size, such as print-ready photographs for a press job. In that case the honest answer is not more compression but a different delivery method, such as a file-sharing link, or splitting the document so each part fits the limit. Split PDF is not the tool for this post's job, but it is worth knowing it exists for the day compression alone is not enough.
FAQs
Why is my PDF so large in the first place?
Usually because of images stored at full camera or scanner resolution, fully embedded fonts, or scanned pages that are images rather than text. Text itself is almost never the problem. Work out which of the three applies before choosing a compression mode.
How do I make a PDF smaller without making it blurry?
Start with the lossless re-save, which keeps text selectable and avoids rebuilding pages. If that is not enough, try the smallest-size rebuild on a copy and inspect the result at normal reading size. Slight softening in photographs is normal; unreadable text means the rebuild went too far for that document.
Will compressing a PDF remove its text layer?
The lossless re-save keeps text selectable. The smallest-size rebuild turns pages into images, so text in the result is no longer selectable or searchable. If you need to search or copy text afterwards, stay with the lossless mode and keep the original as your archive copy.
What if compression alone does not get under the limit?
Check whether every page is needed, and consider sending the document in parts or through a file-sharing link for print-quality material. For pages that must become images for slides or posts, PDF to JPG converts pages at a DPI you choose, and the guide to optimizing images for the web explains the size-versus-quality trade in more depth.
Related reading: Image format choice is often the bulk.
human review pending client designation