Nearly always, one thing is responsible: images stored at a far higher resolution than the page needs. Embedded fonts are the usual second cause, and old revisions kept inside the file are the sneaky third. Text itself almost never matters, because a page of text is only a few kilobytes.
To put numbers on that, we built test files with Python’s reportlab library and measured them. The text file is 10 pages at about 46 lines per page. The photo is a real camera JPEG: a 5919 by 4024 pixel press image from NASA’s library, 17.1 MB on disk.
| What the file contains | Size |
|---|---|
| 10 pages of text, font not embedded (Helvetica) | 19,158 bytes |
| Same text with page streams left uncompressed | 63,722 bytes |
| Same text, Arial embedded as a subset | 51,849 bytes |
| Same text, the whole Arial font embedded | 440,793 bytes |
| 11 pages of text plus one page holding the photo | 17,151,934 bytes |
One photo accounts for more than 99% of that last file. The rest of this guide covers each cause, in the order worth checking.
What a PDF is made of
A PDF is a collection of numbered objects: pages, fonts, images, content streams. A table at the end of the file (the cross-reference table) records where each one starts. Most streams are compressed individually. So file size is the sum of its objects, and you can inspect them one at a time.
Images: check these first
A page does not store “a picture at the size you see”. It stores all the pixels you gave it and scales them to fit. Place a 5919-pixel-wide photo in a 6.5 inch column and every one of those pixels is kept, at roughly 911 pixels per inch. Nothing short of a high-end print press can use that.
If you have Poppler’s command-line tools installed, pdfimages -list shows the resolution of each image as placed. This is the output from our test file:
page num type width height color comp bpc enc interp object ID x-ppi y-ppi size ratio
--------------------------------------------------------------------------------------------
12 0 image 5919 4024 rgb 3 8 jpeg no 14 0 911 911 16.3M 24%
Read the x-ppi and size columns. Anything well above 300 PPI in a document meant for reading is waste, and the same photo at 150 PPI would hold about 1 in 37 of those pixels.
Scanned documents are a special case because every page is an image. A letter page scanned at 300 DPI in colour is 2550 by 3300 pixels, which is about 25 MB of raw data per page before compression. A 40-page scan can easily be larger than a 400-page novel. Run pdfimages -list on one and you will see one image per page. If pdffonts also lists no fonts at all, it has no real text layer.
PNG-style images inside PDFs
The enc column matters too. jpeg means the image was stored with lossy compression. image (Flate compression, the same family as PNG) is lossless, and it is what you get when a photo was pasted from a screenshot or exported carelessly. Photos stored this way can be many times larger than they need to be.
Fonts: small files, surprising share
A PDF can name a font and rely on the reader having it, or carry the font inside the file. For anything you want to look the same everywhere, embedding is right. The question is how much of the font to embed.
A subset holds only the characters the document uses. In our test, subsetting cost 33 KB over no embedding at all, while embedding all of Arial cost 422 KB for exactly the same words. The Arial file on disk is 773 KB. Fonts with large character sets are far worse, because a full CJK font can run to many megabytes.
pdffonts shows what you have:
name type encoding emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
Helvetica Type 1 WinAnsi no no no 2 0
AAAAAA+ArialMT TrueType WinAnsi yes yes yes 16 0
emb means embedded and sub means subset. The six-letter prefix before the plus sign is the mark of a subset. A long list of yes no entries in a small document is your problem. One document exported from several apps can also carry the same typeface many times, once per source.
Old revisions: the deleted content still in the file
This is the cause people rarely suspect. PDF allows an incremental update: rather than rewriting the file, software can append the changed objects and a new cross-reference table to the end. It is fast, and it is the reason a file can get larger after you delete something.
We tested this directly. We took the 12-page file above and appended a hand-written update that removes page 12, the one with the photo.
| Version | Pages | Size |
|---|---|---|
| Original | 12 | 17,151,934 bytes |
| After incremental “delete” | 11 | 17,152,177 bytes |
| Same file, fully rewritten by pikepdf | 11 | 49,925 bytes |
The “deleted” file grew by 243 bytes. The photo was still there, just no longer referenced. Cutting the file off at its first end-of-file marker brought back the original 12 pages, intact.
That has a privacy side as well as a size side. A PDF edited this way can still contain text you thought you removed, so a redaction is only real if the tool rewrites the file.
To check, count the end-of-file markers:
grep -a -c '%%EOF' report.pdf
More than one marker usually means more than one revision. The exception is a linearized “fast web view” file, which normally has two. Digitally signed PDFs also rely on incremental updates, so a full rewrite will break their signatures. Do not rewrite a signed file you need to keep valid.
Less common causes
- Attachments. A PDF can carry other files inside it.
pdfdetach -list file.pdfshows them. Portfolios and some exported reports hide a surprising amount here. - Round-trip data from design apps. Adobe Illustrator’s “Preserve Illustrator Editing Capabilities” option stores a full editable copy inside the PDF. It helps when you reopen the file in Illustrator, and costs space for everyone else.
- Complex vector art. Maps and CAD exports can hold millions of path segments. Those compress reasonably but take no account of your screen, so they can be large and slow to draw at once.
- Uncompressed streams. Rare in files from modern software, but it is the difference between 19 KB and 64 KB in our table. A lossless re-save fixes it.
A five-minute diagnosis
- Look at page count against size. Under about 100 KB per page is normal for office documents. Over 1 MB per page means images.
- Run
pdfimages -list. Sum thesizecolumn. If it is close to the file size, you have your answer. - Run
pdffonts. Look for fonts wheresubsaysno. - Run
grep -a -c '%%EOF'. If the images and fonts do not add up to the file size and you see several markers, the rest is old revisions. - Run
pdfdetach -listto rule out attachments.
If you would rather not use a terminal, Adobe Acrobat Pro’s PDF Optimizer has an “Audit Space Usage” view that breaks the file down by object type. Our PDF Metadata Viewer shows page count, size and which software produced the file, which often hints at the cause, though it does not break down the space.
What to do about each cause
| Cause | Fix |
|---|---|
| Oversized images | Downsample to the resolution your use needs, then recompress |
| Screenshots stored losslessly | Recompress as JPEG unless they are mostly text and lines |
| Full fonts | Re-export with font subsetting on |
| Old revisions | Rewrite the file (a “save as” or a lossless re-save) |
| Attachments | Remove them in a PDF editor if nobody needs them |
Fixing at the source beats fixing afterwards. Resize images before placing them in Word or InDesign, and pick the smaller export preset. If the source is gone, Compress PDF offers both routes. Its Lossless mode rewrites the file and drops unreferenced objects: our incrementally “deleted” file went from 17,152,177 to 46,619 bytes, and the uncompressed text file from 63,722 to 13,665. On the file whose photo was still in use, it saved under 4 KB, because a lossless pass cannot shrink a JPEG. That is the job of image downsampling, which we cover in how to compress a PDF without losing quality.