Why PDF Files Get So Large (And What Actually Shrinks Them)

A four-page PDF has no business being 40MB. Yet it happens constantly, and the usual response — run it through a compressor and hope — treats the symptom without ever asking what went wrong. Understanding where the weight actually sits tells you which fix will work and, more usefully, which ones won't.

There are four common culprits, and they respond to completely different treatments.

1. Images, which are almost always the answer

If a PDF is unexpectedly large, images are the cause roughly nine times out of ten.

The reason is resolution mismatch. A modern phone camera produces images around 4000 pixels wide. Printed at typical document scale, a page needs roughly 2500 pixels across at 300 DPI, and displayed on screen it needs closer to 1000. So a photo dropped into a document often carries three or four times more pixel data than the page can ever display — and PDF stores all of it faithfully, because PDF's job is fidelity.

Scanners make this worse. Scan a page at 600 DPI in full colour and you generate an enormous image for what is, in most cases, black text on white paper. Multiply by thirty pages and a simple contract becomes a file email will reject.

What fixes it: downsampling images to a resolution matched to how the document will actually be used, and re-encoding them with appropriate compression. This is what a PDF compressor does, and on an image-heavy file it can remove 70–90% of the size without any visible difference on screen.

What won't fix it: zipping the PDF. Image data inside a PDF is already compressed, and ZIP cannot meaningfully compress already-compressed data. You will save two percent and gain an extra step for whoever receives it.

2. Embedded fonts, and the subsetting question

PDFs embed the fonts they use so the document renders identically everywhere — the entire point of the format. A single font family with regular, bold, italic and bold-italic can add several hundred kilobytes.

That is usually a reasonable trade. It becomes unreasonable when fonts are embedded in full rather than subsetted. A complete font file contains every glyph the designer drew: several thousand characters covering scripts your document never uses. Subsetting strips that down to only the characters actually present on the page, which for an English-language document is perhaps eighty glyphs.

The difference is dramatic for CJK fonts in particular, where a full font file can exceed 15MB on its own.

What fixes it: exporting with font subsetting enabled. Most modern export paths do this by default; older workflows and some office suites do not.

When you shouldn't: if the PDF is a form other people will fill in, or a template that will have text added later, aggressive subsetting can leave characters unavailable. Keep full embedding for editable documents.

3. Revision history and incremental saves

This one surprises people. The PDF specification allows incremental updates: when you edit a PDF, rather than rewriting the file, an editor can append the changes to the end and leave the original bytes in place.

The practical consequence is that a PDF edited fifteen times may still contain all fifteen previous versions. The file grows monotonically, and the discarded content is still sitting there in the bytes.

There is a security dimension here that matters more than the file size. If you drew a black box over sensitive text and saved incrementally, the original text may still be present in the file — recoverable by anyone who opens it in the right tool. This is the mechanism behind a long series of embarrassing document leaks by organisations that believed they had redacted something.

What fixes it: saving a linearised or "optimised" copy, which rewrites the file from scratch and discards orphaned objects. Any process that fully re-writes the PDF has this effect.

For the security case: use proper redaction that removes the underlying content, not a drawing tool that covers it. Covering is not removing.

4. Metadata, attachments and things you forgot were in there

PDFs can carry file attachments, JavaScript, embedded multimedia, colour profiles, XMP metadata blocks and thumbnails for every page. Individually these are small. Collectively, on a file exported from design software with everything enabled, they add up.

Embedded colour profiles deserve a specific mention: an ICC profile is typically a few hundred kilobytes, and some export presets attach one to every image rather than referencing a single shared profile.

What fixes it: an export preset appropriate to the destination. "Smallest file size" or "web" presets in most design tools strip this material automatically. Print presets deliberately retain it, which is correct for print and wasteful for email.

Working out which one you have

You can usually diagnose by arithmetic rather than tooling.

Divide file size by page count. A text-only page in a well-made PDF is on the order of 20–50KB. A page with a photograph might be 200–500KB. If you are seeing several megabytes per page, you have an image problem. If you are seeing a large file with few pages and no images, suspect fonts or revision history.

Then check whether the size is proportionate to page count at all. A 30MB file with two pages and one logo is almost certainly carrying revision history or an embedded attachment, not image data.

The compression trade-off nobody states plainly

Compression is lossy for images. Each round degrades quality further, and the degradation is cumulative and irreversible.

This has a practical consequence: always keep your original. Compress a copy for sending, and archive the full-quality version. People routinely compress a scanned document, delete the original, and discover months later that the text is now too soft to read reliably — or worse, too soft for OCR to process accurately.

It also means you should compress once, at the end, rather than at each stage of a workflow. A file that has been compressed, edited, compressed, merged and compressed again has been through three generations of quality loss for no reason.

A reasonable default workflow

For most documents heading to email or an upload form:

1. Start from the highest-quality original you have.
2. If it is a scan, consider whether it needs to be in colour. Greyscale roughly thirds the data; pure black-and-white for text documents cuts far more.
3. Run one compression pass at a moderate setting.
4. Check the pages that matter — small text and fine detail first.
5. If it is still too large, go to a more aggressive setting rather than compressing the already-compressed output a second time.

You can do steps 3 to 5 with our free Compress PDF tool, which runs entirely in your browser and shows you the before and after sizes so you can judge the trade directly.

When the file is large for a legitimate reason

Sometimes a PDF is large because it genuinely contains a lot of information. A 200-page technical manual with detailed diagrams is going to be big, and compressing it to fit an arbitrary email limit is the wrong solution to the wrong problem.

In that situation, splitting the document into the section the recipient actually needs is almost always better than degrading the whole thing. Sending someone the twelve pages relevant to them is more useful than sending 200 pages at reduced quality — for them, and for you.