Three culprits, and you almost certainly have one of them
A PDF is a container. Text, fonts, images, vector paths and a pile of invisible bookkeeping all live inside one file, and any of them can be the thing making it enormous.
In practice, though, the answer is nearly always one of three.
Scanned pages. Someone photographed or scanned paper. Every page is now a photograph, and a colour scan at 300 dots per inch runs to several megabytes per page before anything else is counted. A twenty page scanned contract at 40MB is behaving exactly as designed.
Photos dropped in at full resolution. A report with a dozen phone photos carries a dozen 4000 pixel wide images, even though each one is displayed four inches across. The file stores what you gave it, not what it shows.
Fonts embedded whole. PDFs embed fonts so the document looks identical everywhere. Embedding an entire font family, rather than only the characters actually used, can add megabytes to a file whose text would fit in a few kilobytes.
Work out which of the three you have before touching a compressor, because the answer changes what you should do next. Open the file and try to select a sentence with your cursor. If nothing highlights, you have a scan, and no amount of clever compression will turn it back into text.
What compression actually does to your file
Compressing a PDF is not one operation. It is a bundle of them, and they differ enormously in whether anything is lost.
Downsampling reduces image resolution. A 300dpi photo becomes 150dpi, roughly a quarter of the pixels. On screen you will not notice. Printed, you might. This is where most of the saving comes from, and it is irreversible.
Recompressing applies stronger JPEG compression to images already inside the file. Push it far and you get the smeary blocks around text and edges that make a document look cheap.
Font subsetting strips the unused characters out of an embedded font. Nothing visible changes at all. This one is free.
Object cleanup removes orphaned data: revision history, deleted objects still sitting in the file, unused colour profiles, duplicated resources. Also free, and on files that have been edited many times it can be surprisingly large.
The two free operations should always run. The two lossy ones are a trade, and the right amount of trade depends on where the file is going.
Our PDF compressor does this in your browser, which for a signed contract or a scan of your passport is not a small detail: the document never leaves your machine.
How small does it actually need to be?
People compress to a vague sense that smaller is better. Pick a target instead, because the target decides how hard you should push.
Email attachments are the usual reason. Most corporate mail systems reject somewhere between 10MB and 25MB, and the encoding email uses inflates attachments by about a third on the way, so a 20MB file can fail a 25MB limit.
Government and university upload forms are stricter and stranger. Visa applications, court filings and grant portals routinely cap at 2MB or 5MB per document, sometimes per page.
Anything destined for print wants 300dpi images and should not be downsampled at all. Compress that file and the printer will tell you, politely, that it looks soft.
For a document that will only ever be read on a screen, 150dpi is genuinely enough, and most of the 40MB problem disappears at that setting alone.
When splitting beats compressing
Here is the move people forget. If the limit is per file rather than total, you do not have a compression problem, you have an arithmetic problem.
A 30MB scanned report will not squeeze under a 10MB cap without visible damage. Split into three parts, each lands comfortably under, and nothing is degraded at all. Portals that cap per document usually accept several documents.
The same logic runs the other way. Fifteen separate scans of one contract, each a couple of megabytes, are a nuisance to whoever receives them and often larger in total than one merged file, because each carries its own copy of the shared overhead.
So: split when a hard cap is the obstacle, merge when the obstacle is the recipient's patience.
One caution on merging. Combining ten files means combining ten sets of embedded fonts, and unless the merger deduplicates them you keep all ten. Running a cleanup pass after a big merge is usually worth it.
The scan problem, which compression does not solve
A scanned PDF is images pretending to be a document. You cannot select the text, search it, or copy a paragraph out, because as far as the file is concerned there is no text, only pictures of letters.
That has consequences beyond size. Screen readers cannot read it. Search engines cannot index it. A colleague cannot ctrl-F for the clause they need. If you are producing documents other people rely on, a scan is a poor format even when the size is fine.
The fix is OCR, which recognises the shapes and adds a searchable text layer underneath the image. Note what it does not do: the images stay, so the file usually gets slightly larger rather than smaller. OCR solves usability, not size. Treat them as separate jobs.
Better still, avoid creating the problem. If the document started digital, export it as a PDF rather than printing it, signing it, scanning it and sending back a photograph of your own document. The signed-scan-of-a-print loop is how a 200KB file becomes 30MB. When you genuinely do need to build a PDF from photographs, image to PDF at least lets you set a sensible resolution on the way in.
Questions people ask
Usually scanned pages, full resolution photos, or fonts embedded in their entirety. Try to select text with your cursor: if nothing highlights, the pages are images and that is your answer. If text selects but the file is still huge, look at the images first and the fonts second.
Some of it does. Font subsetting and removing orphaned objects change nothing visible. Downsampling images and recompressing them are lossy and irreversible, which is fine for screen reading and a problem for print. A good compressor runs the free operations first.
150dpi for anything that will only be read on a screen, 300dpi for anything that will be printed. Most oversized PDFs are carrying 300dpi or higher images for a document nobody will ever print, and dropping to 150 removes most of the bulk on its own.
Most systems reject somewhere between 10MB and 25MB, and email encoding inflates attachments by roughly a third in transit, so aim below 10MB to be safe. Above that, a shared link avoids the problem entirely and does not degrade the file.
Split, if the obstacle is a hard per file limit. A 30MB scan will not reach 10MB without visible damage, but three 10MB pieces arrive intact. Compress when you need one file and have room to trade a little quality.
Only with OCR, which adds a text layer beneath the page images. Worth knowing: it does not shrink the file, and often adds slightly to it, because the images remain. Searchability and size are separate problems with separate fixes.
Every PDF tool here runs in your own browser, so the file is read and rewritten on your device and never uploaded. That is the part that matters for a contract, a medical letter or a scan of an ID document, where the usual advice to just use any free converter is genuinely bad advice.
.jpeg)