A PDF is a bundle, not a single image
It helps to stop thinking of a PDF as one flat thing and start thinking of it as a zip bag full of separate parts. Inside a typical PDF you will find text and its layout instructions, one or more embedded fonts, any images placed on the pages, vector graphics, and a layer of metadata describing the whole document. The final file size is simply the sum of all those parts plus the overhead of how they are packaged. When a PDF is surprisingly large, one of those parts is usually doing most of the damage.
Culprit one: scanned and photographed images
This is the single most common reason for a bloated PDF. A modern phone camera captures 12 megapixels or more. When you photograph a document and drop it into a PDF, that full-resolution image goes in at its native size. One page can easily be three to five megabytes. A ten-page scanned contract can be forty megabytes without a single line of selectable text.
The fix is to reduce the resolution and recompress the images before or during PDF creation. A document does not need 12 megapixels to be perfectly readable — screen and print legibility is reached long before that. Compressing the images to a sensible resolution can shrink a scanned PDF by 80 to 95 percent with no meaningful loss in readability.
Culprit two: fully embedded fonts
PDFs embed fonts so the document looks identical on every device, even ones that do not have the font installed. That is a good thing for consistency, but it has a cost. If a document embeds several full font families — regular, bold, italic, and bold-italic for two or three typefaces — that can add hundreds of kilobytes before you have written a word.
Well-behaved export tools embed only font subsets, meaning just the characters actually used. Poorly configured ones embed the entire font. If a small text document is mysteriously large, over-embedded fonts are a likely suspect, and re-saving through an optimiser that subsets fonts can help.
Culprit three: redundant internal structure
Every time a PDF is edited, annotated, merged, or re-saved by different software, it can accumulate cruft: duplicated objects, orphaned data from deleted pages, uncompressed streams, and revision history. A PDF that has been through several tools is often carrying dead weight that has nothing to do with what is visible on the page.
This is where lossless structural optimisation helps. Rewriting the PDF with object streams enabled compresses the internal cross-reference data and removes redundancy, often reclaiming a surprising amount of space without changing a single pixel of the visible document.
The right order of operations
If you want the best result with the least quality loss, tackle the causes in this order:
- Start with structural optimisation. Run the PDF through a compressor that rewrites it losslessly. For text-heavy documents, this alone may be enough.
- If it is still too large, look at the images. If the document is a scan or contains photos, compress those images before rebuilding the PDF.
- Check the fonts. If you control the export, choose 'subset embedded fonts' rather than full embedding.
- Re-measure after each step. Stop as soon as you are under the size limit you need — over-compressing only costs you quality.
How small should you actually aim for?
There is no universal target. Let the destination decide. If an upload form caps at 5 MB, getting to 4 MB with the pages crisp and readable is a better outcome than crushing the file to 500 KB and blurring the fine print. File size is only a problem when it exceeds a limit or slows down sharing. Below that, sharpness and legibility matter more than squeezing out every last kilobyte.
Key takeaways
- Scanned images are the number-one cause of large PDFs; reducing their resolution has the biggest impact.
- Over-embedded fonts and redundant structure add invisible weight.
- Optimise structure first (lossless), then images (lossy), then fonts.
- Aim for the destination's limit, not the smallest possible file.