Search "compress PDF online" and you will land on a dozen sites that look nearly identical: a big upload box, a progress spinner, and eventually a "your file is ready" screen with a download link. What almost none of them tell you plainly is that your file spent that spinner-time sitting on a server you have no relationship with, being processed by code you cannot inspect, on infrastructure with its own retention policy that you almost certainly did not read. That workflow exists because it is easy to build, not because compression genuinely requires a server.
PDF compression is really a handful of well-understood, mechanical transformations, and every one of them is achievable with JavaScript running in a browser tab. The biggest single lever is usually image re-encoding: PDFs that started life as scanned documents or exported slide decks often embed images at a much higher resolution and quality than the page will ever display them at. Down-sampling those embedded images to a sane DPI for on-screen or even most print use, and re-encoding them with a slightly more aggressive JPEG quality setting, routinely cuts file size by 60-90 percent with no visible difference at normal zoom levels.
The second lever is structural cleanup: removing duplicate font subsets, stripping unused embedded objects, and re-writing the PDF's internal cross-reference table more compactly. None of this requires understanding the meaning of your document's content — it is byte-level and object-level housekeeping on the PDF's internal structure, exactly the kind of task a library like pdf-lib, running entirely inside a Web Worker in your tab, is built to do.
On minipdftoosz, the Compress PDF tool exposes this as a simple compression-level choice, but underneath it is doing real work: decoding each embedded image, deciding on an appropriate down-sampled resolution and JPEG quality based on the level you picked, re-encoding, and re-assembling the PDF with the smaller images swapped back in. Because this happens locally, there is an honest trade-off worth naming: client-side compression, running on your device's CPU inside a browser's constraints, can be somewhat less aggressive on certain heavily-optimized scanned documents than a dedicated server-side compression pipeline with more exotic image codecs available to it. For the vast majority of everyday PDFs — reports, forms, slide exports, scanned receipts — the difference is not something you will notice, and the trade is clearly worth it for never having to hand the file over in the first place.
There is a second, related use case worth mentioning: converting PDF pages to compressed image formats directly. The PDF to JPG and PDF to WebP tools on this site follow the same pattern in reverse — pdf.js renders each page to an in-memory canvas, and the canvas is then encoded to a compressed image format locally, with WebP in particular often producing noticeably smaller files than JPEG at comparable visual quality for the same page content.
The pattern that matters here generalizes past just Compress PDF: any tool that claims to "process" your file but requires an upload first is making an architectural choice, not a technical necessity. Whenever the actual transformation is expressible as JavaScript or WebAssembly — which covers the overwhelming majority of common PDF operations — there is no good reason your file needs to leave your device at all.