The email bounces. The upload form says 25 MB. You look at the file, which is eight pages of a contract, and cannot see where forty megabytes could possibly be hiding. They are hiding in plain sight: you are not sending eight pages of a contract, you are sending eight photographs.
The arithmetic nobody does
An A4 page is 8.27 by 11.69 inches. A scanner set to 300 dots per inch — the default on almost every machine — records 2,480 by 3,508 pixels for it.
That is the whole explanation. Your scanner is a camera, its default is roughly a phone camera's resolution, and you pointed it at twenty pages. The file is large for exactly the reason a folder of twenty holiday photos is large.
The 600 dpi setting, which sounds like twice as much, is four times as much: pixels are counted along both edges, so doubling the resolution quadruples the count. People select it because it sounds careful, and for a printed page of text it recovers nothing a reader will ever see.
What a typed PDF contains instead
A page exported from a word processor stores drawing instructions and a font. The instructions are short — a position, a font reference, a string of glyph codes — and they compress well because prose is repetitive.
The font is usually the largest single thing in the file, and it is stored once no matter how many pages use it. Which is why the second page of a typed PDF costs almost nothing and the second page of a scan costs as much as the first. A 200-page typed report can be smaller than a 3-page scan, and regularly is.
What compression can actually recover
The images inside a scanned PDF are already JPEGs. They were compressed by the scanner once. So the honest question is not "can this be compressed" but "was the scanner's setting more generous than it needed to be", and the answer is usually yes.
Three things are worth recovering, in this order.
Resolution. If the document will be read on screen and never printed, 150 dpi is legible and is a quarter of the pixels. This is the largest single saving available and the one people skip, because it feels like throwing something away — which it is, and the thing being thrown away is invisible on a screen.
Quality. Re-encoding the JPEGs at a lower setting. Worth doing, with one caveat that matters more here than for photographs: text has hard edges, and JPEG is bad at hard edges. Push the quality down far enough and the letters grow a grey halo. Photographs tolerate quality 60; a scan of text does not.
Colour. A black-and-white document scanned in colour stores three channels of nearly identical data. Greyscale is a third of the size before any other change, and for a page that was black ink on white paper it removes nothing at all except the faint yellow of the paper.
A compressor that does these three does the whole job. Anything claiming more is either doing one of these and describing it grandly, or doing the thing in the next section.
The trick that makes it worse
Some tools shrink any PDF by rasterising it: rendering every page to an image and building a new document out of the pictures. It reliably produces a smaller file when given a scan, and it is a catastrophe when given a typed one.
A typed page turned into an image loses its text. Selection stops working, search stops working, screen readers stop working, and the file usually gets larger, because a page of crisp text is expensive to store as pixels and almost free to store as glyph references. You have paid megabytes to destroy the useful part of the document.
This is worth checking before trusting any compressor: run it on a typed document, then try to select a word in the result. If you cannot, the tool rasterises, and you should not use it on anything.
When a PDF will not shrink
A typed PDF is already close to its floor. There is compression to be had in the object streams and there are duplicate resources to merge, but the numbers are single-digit percentages, not the 70% people expect from the word "compress". A tool that reports 3% on your report is not failing; there was 3% there.
A PDF that has already been compressed hard will also refuse. Re-encoding a JPEG at quality 60 that was already saved at quality 50 produces a larger file, because every JPEG generation adds artefacts and artefacts are detail, and detail is what costs bytes. A compressor worth using notices this and keeps the original stream rather than triumphantly reporting a size increase.
Vector artwork will not shrink either. A map or a CAD drawing is thousands of individual paths, all of them meaningful, none of them redundant. The file is large because the drawing is complicated.
The other things in the file
Occasionally the size is not the pages at all. Embedded fonts that were never subset can add a megabyte each — a full CJK font is enormous, and some exporters embed the whole thing to render four characters. Attachments ride along invisibly. Revision history from an editor that saved incrementally leaves every earlier version in the file, which is both a size problem and a disclosure problem.
The tell for all of these is a file whose size does not match its page count in either direction — four pages at 30 MB, or a scan that is somehow smaller than it should be.
The short version
Scans are photographs and are large for that reason. Scan at 300 dpi, in greyscale, and only go to 600 if someone will reprint it. If the file is already made, drop the resolution before touching the quality — it is the bigger saving and it costs nothing on a screen.
And check that whatever you use has not turned your text into a picture, because the file that shrank the most is very often the one that was quietly ruined.