Why Is My PDF So Large? The Causes and the Real Fixes
A forty-page report comes in under a megabyte. A four-page scan of the same document comes in at forty. Both are PDFs, both look similar on screen, and the difference is not a mistake — it is the single most useful thing to understand about PDF file size.
First, work out which kind of large you have
Everything else follows from this, and it takes five seconds.
Try to select the text with your cursor.
Nothing highlights. The pages are images — a scan, a fax, or photographs of paper. This is by far the most common cause of an oversized PDF, and it is the one that compresses well.
Text highlights normally. The pages contain real characters, and something else is making the file big: images placed inside it, embedded fonts, or accumulated edits. Compressing a document like this is usually the wrong move, for reasons set out below.
If you are unsure, divide the file size by the page count. A text page is typically tens of kilobytes. A scanned page is typically hundreds of kilobytes to several megabytes. A document averaging more than about half a megabyte per page is almost certainly image-based. The distinction is the same one behind why a PDF is not searchable.
Cause 1: the pages are pictures of paper
Text is astonishingly cheap to store. A character is a reference to a glyph plus a position — a few bytes. A page of prose might be two or three kilobytes.
A photograph of that same page has to record every pixel. At 300 dots per inch, a letter-size page is 2,550 × 3,300 pixels — roughly 8.4 million of them. Even compressed, that is hundreds of kilobytes for a page whose text would have been three.
So a scanned document is not “a PDF that got big”. It is a stack of photographs in a PDF wrapper, and it weighs what photographs weigh.
The two settings that decide everything
Most oversized scans come from two choices made at the scanner, and the difference between them is not small.
Resolution. Doubling the DPI quadruples the pixel count, because it doubles in both directions. A page at 600 DPI has four times the data of the same page at 300 DPI.
Colour mode. Full colour stores three values per pixel. Greyscale stores one. That is a factor of three before any compression.
Put together, a page scanned at 600 DPI in colour carries roughly twelve times the raw data of the same page at 300 DPI in greyscale — 101 million values against 8.4 million. For a page of black text on white paper, essentially all of that extra data describes nothing.
300 DPI greyscale is the right default for documents. It is above the threshold where text stays crisp and OCR works reliably, and it is what almost every archive and submission standard expects. Reserve colour for pages where colour carries meaning, and 600 DPI for fine detail like engineering drawings or small print you genuinely need to enlarge.
What actually shrinks a scan
Since the images are the file, the only thing that meaningfully reduces the size is re-encoding those images at a lower resolution. Compress PDF does this in your browser: each page is re-rendered at a chosen quality and the document is rebuilt from the results, with nothing uploaded.
The reduction is usually large, because the original was usually scanned at a resolution far beyond what the page needs. Check a page or two afterwards — particularly small print and figures — before discarding the original.
If you still have the paper, rescanning at sensible settings beats compressing. Re-encoding works from what the scanner captured; scanning correctly the first time avoids creating the problem. Compression is the fix when the paper is gone or the scan came from someone else.
Cause 2: images inside a text document
A document with real text can still be enormous if it contains photographs, screenshots, or charts placed at their original size.
A modern phone photograph is several megabytes. Drop six into a report and the report is thirty megabytes, however little text it contains. The images are rarely displayed at anything like their captured resolution — a photo occupying a quarter page is being shown at perhaps a tenth of its pixel count, and the rest is stored and never seen.
The fix belongs in the source document, not the PDF. Resize images before placing them, and export using whatever “reduce file size” or “screen quality” option your software offers. Exporting the same document twice — once for print, once for sharing — takes seconds and is the difference between forty megabytes and four.
Cause 3: embedded fonts
Fonts are stored inside the file so the document renders identically everywhere. That is a feature, and it is why a PDF looks the same on a machine that has never seen the typeface.
The cost depends on how it was embedded. A subset contains only the glyphs actually used — usually tens of kilobytes. A full embed contains the entire typeface, including every character you never typed, and can run to hundreds of kilobytes per font. A document using four weights of two families, each fully embedded, carries a surprising amount of nothing.
This rarely makes a document enormous on its own, but it is often why a short text document is a megabyte rather than fifty kilobytes. Most export settings offer font subsetting; it is worth turning on.
Cause 4: everything the file has been through
A PDF can grow simply by being edited.
The format supports incremental saving: rather than rewriting the file, an application can append changes to the end. It is fast and it makes recovery easier, and it means each save adds rather than replaces. A document edited twenty times can carry all twenty rounds, including content long since deleted. The structure that allows this is part of the format as defined in ISO 32000-2, and the PDF Association publishes reference material on how documents are built.
Other accumulations are quieter: embedded page thumbnails, form field data, annotations, attached files, and metadata from every application that has touched it.
There is a useful signal here. If a document is far larger than its visible content justifies — a ten-page text file at fifteen megabytes with no images — something invisible is being carried. Re-exporting from the source produces a clean file without the history.
When compressing is the wrong answer
This is where most advice on this subject stops short, so it is worth being direct.
Compressing a text-based PDF turns its text into pictures. Search stops working, text can no longer be selected or copied, screen readers can no longer read it, and the file usually gets larger — because you have replaced compact characters with photographs of characters.
That is not a flaw in any particular tool; it is what re-encoding pages as images means. Compress PDF checks which kind of document you have before you start and says so plainly, and if the result comes out bigger it reports that rather than claiming a saving.
If a text document is too big to send, the useful options are different:
- Send part of it. Extract the pages the recipient actually needs. A twelve-page contract is often three pages of substance and nine of schedules.
- Split it. Divide it into several files that each fit, which is covered in how to split a PDF.
- Re-export from the source with images resized and fonts subset.
- Share a link instead of an attachment.
All of these keep the text intact. Compression does not.
A practical order of attack
Work down this list; stop when the file is small enough.
- Identify the type. Select some text. Images or characters — the answer changes everything below.
- If it is a scan: compress it. This is the case where compression is genuinely the right tool and the reduction is real.
- If it has text and images: go back to the source, resize the images, export again.
- If it has text and no obvious images: it is probably carrying history or full fonts. Re-export from the source.
- If none of that is possible: send fewer pages, or split the file.
- If you are creating the scan: fix it at the scanner. 300 DPI greyscale, and colour only where colour means something.
Keep the original
Whichever route you take, keep what you started with.
Compression is not reversible — the discarded detail is gone, and the text a scan might once have had a layer for is now part of an image. Splitting loses the whole. Re-exporting may lose something you did not notice.
Every tool here writes a new file and leaves the original untouched, which makes this easy: the compressed copy is what you send, the original is what you keep. If the compressed version turns out to be too soft to read, you still have something to try again from.
If the scan also needs to be searchable
One sequencing note, because the order matters and only one of the two orders works well.
Compression rasterises pages, which discards any text layer the file had. So if a scan needs to be both smaller and searchable, compress first, then run OCR on the result. Doing it the other way round means recognising text that is about to be thrown away.
Recognition also performs better on a clean page, so rotating pages upright and cropping scanner edges first is worth the minute it takes. See how OCR makes scanned PDFs searchable for what to expect from the result.
Everything above runs in your browser. A document too large to email is often a document you would rather not upload to a stranger’s server in order to make it smaller — which is the whole reason these tools work the way they do.