How to compress a PDF entirely in the browser
Shrink a PDF without uploading it anywhere. Walks through how image re-encoding and stripped objects reduce file size in the browser, with notes on quality trade-offs.
Why some PDFs refuse to shrink
The bulk of a large PDF is almost never the text — it is the images embedded inside the pages. Scanned documents, photographed receipts pasted into an expense report, and specifications full of screenshots each carry several hundred kilobytes to a few megabytes of JPEG or PNG streams per page. A 300-dpi scan of A4 paper is 2480 × 3508 pixels, so a 20-page scanned PDF easily crosses 50 MB before you notice.
The constraints come quickly. Gmail caps attachments at 25 MB. Many job application forms and government submission portals draw the line at 5–10 MB. Receiving mail servers can drop a huge attachment in front of their virus scanner, never giving the recipient a chance to see it. To stop choking the “delivery” step you typically need to shrink an image-heavy PDF to a third or a tenth of its original size — which is exactly what the in-browser PDF compress tool is built for.
The actual steps in the browser
Open pdf-compress and drag-and-drop one or several PDFs into the page. After load you get two sliders: max image width (in pixels) and JPEG quality (0–100). Max width caps the rasterised resolution; 1500–2000 px keeps A4 readable on screen and on a printer, while 1200 px is usually still legible for email attachments. JPEG quality between 60 and 75 hits a reasonable balance — drop below that and you start seeing classic JPEG ringing artefacts on text edges.
Run the compression and the tool shows the before/after sizes and the reduction ratio for each file. Multiple inputs can be downloaded as a single ZIP. Because no PDF is uploaded, the DevTools Network tab stays quiet during compression — only the initial script and WASM fetches appear, and nothing tied to the file content goes out afterwards.
What actually does the work — image re-encoding or object stripping
For image-heavy PDFs the dominant term is the image re-encoding. Each page is rasterised to a canvas, then re-encoded as JPEG, and the duplicate objects, page thumbnails, OCR overlay layers, edit history, and PDF/A or signed-version metadata that the original file accumulated are all dropped along the way. With max width 1500 and quality 70 a typical photo-scan PDF tends to land at 20–40 % of its original size.
This is also why text-heavy PDFs do not benefit much. A document that already stores fonts and shapes as native PDF vectors has very little overhead to strip out, and rasterising-then-JPEGing it throws away vector information for nothing — text actually looks worse. For text-first PDFs the better strategy is to drop unnecessary pages with pdf-split and pull out only the ranges you need.
What you give up with an upload-style compressor
Searching for “PDF compress” surfaces dozens of services that let you pick a file in your browser and then ship it to their backend. The interface looks identical, but contracts, résumés, receipts, and HR paperwork get copied to someone else’s server — and that is a structural change in your data flow. Most of those services’ terms of use include a clause along the lines of “you grant us a non-exclusive license to the content you upload”; even if they honour a deletion request, you cannot audit the CDN caches, server logs, or backup snapshots that already touched the file.
In-browser compression has no code path that uploads the document at all. pdf-compress is built on top of pdf-lib, the Canvas API, and the browser’s JPEG encoder; the source is auditable on GitHub. Being able to confirm with DevTools and the public source that the file never left your tab is a different kind of guarantee than trusting a privacy policy after the fact.