Compress a large PDF — without uploading it
Big scans and image-heavy files shrink the most. Nothing is uploaded, so size costs you no waiting.
Big scans and image-heavy files shrink the most. Nothing is uploaded, so size costs you no waiting.
Every browser-based compressor handles a 2 MB file. The problems start at 50 MB, 200 MB, a scanned book. Upload-based services meet that with queues, size caps and timeouts, because the file has to cross the network twice before anything happens — and the bigger it is, the more likely the round trip fails halfway.
PDFfit never uploads, so file size costs you nothing but local processing time. There is no cap on what you can open; the practical ceiling is your own device's memory, since the document is held there while it is rewritten.
A large PDF is almost always large because of images, not text. A scanned document stores a full photograph of every page. A report with screenshots keeps each one at original camera resolution even though it displays at a fraction of that size.
Compression works by downsampling those images and rebuilding the document around them — the same thing desktop tools do, using Ghostscript compiled to WebAssembly. That is why scanned and image-heavy PDFs typically drop 60–90%, while a text-only PDF is often already near its floor and barely moves. If a file cannot be made smaller, you keep your original rather than a degraded copy of the same size.
No fixed limit. Because the work is local, the ceiling is your device's available memory rather than a server-side cap.
No. That matters most at this size — a large PDF is usually a scan of something you would not hand to an unfamiliar server, and there is no copy to delete afterwards.
It is probably mostly text. The savings come from images; a text-only file is already close to as small as it gets.
Compress any PDF · Step-by-step instructions · Privacy policy