Updated September 2026
Every PDF you compress here is processed by the same short pipeline, running entirely in your browser tab via WebAssembly. No file is ever uploaded — there is no upload endpoint in this tool's code to upload it to. This page explains exactly what that pipeline does, step by step, so you know what "compressed" actually means before you send the result to anyone.
The compression itself runs on MuPDF, an open-source PDF toolkit, compiled to WebAssembly and downloaded once when you first load the page (a few megabytes — after that, the tool works even offline). Your browser executes it directly; there's no server-side component doing the actual compression work, which is also why there's genuinely nothing to upload.
The first pass rewrites your PDF's internal structure: it recompresses embedded images with tighter encoding, recompresses embedded fonts, and deduplicates repeated objects (the same image or resource referenced multiple times in a document only needs to be stored once). This pass is close to lossless from a visual standpoint — pages look the same, text stays exactly as sharp and exactly as selectable as before. For PDFs that are already well-optimized text documents, this pass alone is often the only one that runs, because it's usually all there is to gain.
For image-heavy files — scans especially — a second pass renders every page to a flat image at 150 DPI and re-encodes it as a JPEG at quality 68, then rebuilds a new PDF from those images. This pass is genuinely lossy: a page that goes through it becomes a picture of that page rather than the original vector/text content. The tool only keeps this result if it's meaningfully smaller than pass 1's output — smaller by at least 8%, and no less than 3% of the original file size or 1KB (a basic guard against ever producing a corrupted-looking near-empty file). If pass 2 doesn't clear that bar, pass 1's result is kept instead.
Whether your final file's text stays selectable depends on which pass wins. For a scanned document, there generally wasn't any selectable text to begin with — it was already a picture of a page before you ever touched this tool — so pass 2 winning costs you nothing you had. For a genuinely text-heavy PDF (a report, a contract typed and exported to PDF), pass 1 nearly always wins on its own, because rendering real vector text back down to a 150 DPI JPEG rarely beats how efficiently that text was already encoded — so selectable text is preserved in the common case. If you need certainty for a specific file, open the result and try selecting text before you rely on it.
After both passes, the tool compares the best result against your original file size. If neither pass produced something smaller, you get your original file back, untouched — the tool never hands you a "compressed" file that's actually bigger. This matters for PDFs that arrive already optimized (many modern export tools compress reasonably well on their own); there's nothing wrong with a result that says "already optimized."
You don't have to take this on faith. Open your browser's DevTools, switch to the Network tab, and compress a file — you'll see zero requests fire during compression. The whole operation reads your file into memory, runs the two passes above, and hands you back a download link built from that in-browser result. See the privacy policy for the full data-handling picture.
Full walkthroughs of specific cases: what changes when you're worried about quality, and why scanned PDFs shrink the most.