You attach the document, you hit send, and the mail server hands it straight back. 34 MB, and the limit is 25.
It is almost always the pictures
A PDF is a container. Text inside one is astonishingly cheap — a page of prose costs a few kilobytes, because what is stored is not a picture of the words but the words themselves plus instructions for drawing them. You could put a novel in a PDF and struggle to reach a megabyte.
Images are the opposite. A single photo from a modern phone camera is twelve megapixels of data, and when you drop four of them into a document you are carrying roughly four photographs' worth of bytes plus a thin wrapper. That is the whole story of most oversized PDFs: not the pages, not the fonts, not some mysterious bloat. The photos.
This is why the file size feels so disconnected from the page count. A forty-page contract can be smaller than a two-page scan, and both are behaving exactly as designed.
Why “just compress it” often makes things worse
The blunt approach is to rasterize: take every page, render it to an image, squash the image, and write the results back out. It reliably shrinks the file. It also destroys the document.
Once a text page has been turned into a picture of a text page, the text is gone. You cannot select it, cannot search it, cannot copy a reference number out of it. Screen readers cannot read it aloud. If the document had a searchable layer from OCR, that is gone too. The file is smaller and the document is worth less.
Plenty of tools do this by default, because it is simple to implement and the number on the screen goes down. The number going down is not the goal.
The distinction that matters
The useful approach treats pages differently depending on what is on them. Before touching anything, look at each page and ask what it is made of: how many glyphs are drawn, how much of the page area an image covers, whether there are vector paths.
A page that is essentially a photograph can be rebuilt aggressively — there is nothing on it to destroy. A page carrying text or line art should be copied across byte-for-byte, untouched, exactly as it arrived. Most real documents are a mix, and handling the mix correctly is the difference between a smaller file and a damaged one.
Recto does this per page, and when the classification is ambiguous it fails toward leaving the page alone. A slightly larger file is a recoverable disappointment; a document whose text has been flattened into pixels is not.
Aim at a size, not at a slider
Most compressors give you a quality slider and let you find out afterwards whether you cleared the limit. That is backwards. You do not want “medium quality”; you want under 25 MB, because that is what the mail server said.
Working toward a target means sampling the document, estimating the settings that would land near the number, doing a full pass, measuring the actual result, and correcting. It costs more computation than a fixed slider, and it answers the question you actually asked.
It also means the tool can tell you honestly when it cannot get there. A document that is already efficient has no room, and a compressor that claims otherwise is lying to you.
The uploading problem
Nearly every convenient PDF compressor on the web works by receiving your file. You are asked to upload a bank statement, a signed contract, a photograph of your passport, to a server you know nothing about, so that arithmetic can be performed on it and the result handed back.
For a holiday snap, fine. For the documents people most often need to shrink — precisely the identity and financial documents that come as huge scans — it is a strange bargain, and the reason so many of these services carry a nervous paragraph about deleting files after an hour.
None of the work requires a server. Your phone has the processor for it. Recto does the whole thing on device, which is less a privacy feature than an admission that there was never a reason to send the file anywhere.