PDF Compressor

How offline PDF compression works

This page uses two open-source libraries that run entirely in your browser: Mozilla pdf.js to parse and render your PDF, and jsPDF to write a new compressed PDF. No data leaves your device.

The process has three steps:

1. Parse. pdf.js reads the original PDF and extracts each page as a separate image at the DPI you select.
2. Re-encode. Each page image is compressed as a JPEG at the quality level you choose (default 75%). This is where most of the size reduction happens — PDFs of scanned documents often contain uncompressed or lightly-compressed images, which shrink dramatically when re-encoded.
3. Rebuild. jsPDF combines the compressed page images into a new PDF, page by page. The original PDF is discarded.

You control two levers: DPI (resolution — lower means smaller file, sharper means more detail) and JPEG quality (compression — lower means more artifacts but smaller file). The "Estimated" size box updates in real-time as you adjust either setting.

Why this is the most private way to compress a PDF

Every popular "free PDF compressor" on the web — Adobe, Smallpdf, iLovePDF, PDF24, Canva, FreeConvert, CleverPDF — works by uploading your PDF to their server, processing it there, and sending the compressed version back. This works fine for vacation itineraries, but is a serious problem if your PDF contains:

• Tax returns — social security numbers, income, dependents, banking details
• Medical records — diagnoses, prescriptions, insurance information
• Legal contracts — settlement amounts, party names, signatures
• Financial statements — account numbers, balances, transaction history
• Immigration documents — visas, passports, work permits, background checks
• Anything you'd want shredded instead of recycled

Even if the operator promises to delete your file after processing, the architecture is wrong: the file exists on their server, in memory or in a temp directory, for the duration of the request. Network monitoring, server breaches, insider threats, or simple bugs can all leak it.

This tool runs entirely in your browser. There is no upload endpoint. There is no server-side process. The architecture itself makes leakage impossible — not because we promise to be careful, but because there is nothing to be careful with.

How to verify it's really offline

You don't have to trust us. Verify it yourself:

1. Open your browser's DevTools (right-click → Inspect, or F12).
2. Switch to the Network tab and clear it.
3. Drop a PDF onto the compressor above.
4. Watch the Network tab — it stays empty during compression. No XHR, no fetch, no WebSocket. Nothing.

Alternatively: load this page, then turn off your wifi or unplug your ethernet. The compressor still works because everything it needs is already in your browser. If it needed a server, it would stop working when you go offline.

"No upload" vs "private"

Most "private PDF compressors" say one of these:

• "Files are deleted after compression" — meaning they were uploaded first.
• "Encrypted in transit" — meaning they're transmitted, just over HTTPS.
• "We don't store your files" — relying on the operator's promise rather than architecture.
• "GDPR compliant" — a regulatory claim, not a technical one.

All of these still involve your file existing on someone else's server, even briefly. That's a fundamentally different threat model from the file never being transmitted at all.

This compressor is the second kind. The file is read from your disk, processed in your browser's memory, written to your disk. It never crosses the network boundary. DevTools will show you this in real-time.

What about text sharpness in compressed PDFs?

The compression technique re-encodes pages as JPEG images, which means text is rasterized (turned into pixels) at the chosen DPI. This has tradeoffs compared to a vector-text PDF:

• At 150 DPI or higher with 75%+ quality: text is crisp and readable. Most people cannot tell the difference from a vector PDF on screen.
• At 96 DPI: text is slightly soft but still legible. Fine for screen viewing, email, and small prints.
• At 72 DPI: text becomes noticeably soft. Good only for screen-only viewing at smaller sizes.
• For text-perfect output: this technique is not the right tool. Text-heavy documents that need pixel-perfect typography should use a different approach (pdf-lib's object-stream compression, or Ghostscript's font subsetting — both run on a server).

For most everyday use cases (sharing tax returns, emailing contracts, compressing scanned documents), 150 DPI is the right tradeoff: smaller file, perfectly readable.

Limits and when to use a different tool

• Encrypted PDFs cannot be parsed by pdf.js without a password. Decrypt first or use Adobe Acrobat.
• PDFs with interactive forms (AcroForm, XFA) lose form fields when re-encoded as images. Use PDF Tools for form-based workflows.
• Tagged / accessible PDFs lose their accessibility tree when re-encoded. Adobe Acrobat's "Save As Other → Optimized PDF" preserves the structure.
• Print-quality (300+ DPI) PDFs can be made smaller, but the output is at the same DPI you selected — there is no benefit to selecting 300 DPI if you do not need print quality.

For these cases, the tool will still produce a smaller file — you just lose the original features. Use it for sharing, archiving, and email, not for archival preservation of complex PDFs.