How to compress a 100MB PDF locally
Updated 18 August 2026
Open Compress PDF, drop the file in and choose Balanced. On 15 August 2026 a 118.99 MB, 300-page scan finished in 15.5 seconds in Chromium at an output-to-input ratio of 0.342. The same file and setting returned 0.387 in Firefox and 0.565 in WebKit, because the browser’s own image encoder does the work.
Shrink a 100MB-plus PDF in your browser with no upload — and the measured reason the same file gives three different results in three browsers.
UnboundPDF is a free suite of 43 PDF and image tools that run entirely in your browser — merge, split, compress, edit text, OCR in 126 languages, redact, sign, convert and archive to PDF/A. Your document is read and written by the page on your own device; there is no document-upload endpoint in the core tools, no account, no watermark and no daily cap. Every result can be checked — with the Network tab, or with the Document Passport the Workspace writes for a chain of steps.
- Open Compress PDF and drop in the file — nothing is uploaded, so a 100 MB document costs no upload time at all.
- Choose Balanced first. It re-compresses the photographs inside the document rather than re-rendering every page.
- Start, and watch the page counter. Stop is live throughout.
- Check the sizes the tool reports when it finishes — it tells you when a mode made the file larger instead of announcing a win.
- Reopen the result in a different PDF reader before you send it, which is the check we run on our own outputs.
A 100 MB file never leaves the tab, so there is no upload wait before the work starts and no server copy afterwards. Every figure below names its browser, its date and the document it was measured on.
The number nobody else will give you
Most compression pages advertise a single percentage. We measured why that is not a real number. On 15 August 2026, driving Compress PDF through the real interface with identical input, the identical Balanced setting and the identical slider position, a 118.99 MB 300-page scan came out at an output-to-input ratio of 0.342 in Chromium — a 66% reduction. The same file and setting returned 0.387 in Firefox, a 61% reduction. In WebKit, Safari’s engine, it returned 0.565 — a 43% reduction. Same document, same button, three answers.
The mechanism is in the code the measurement pointed at. Balanced re-quantises embedded JPEGs arithmetically, in plain JavaScript, and that path is identical everywhere — which is exactly what the text-only fixtures show, at 0.986 on all three engines on 15 August 2026. But a photograph above 150 DPI for its page box takes another route: decoded, downsampled through a canvas, and re-encoded by the browser’s own JPEG encoder. Every scan in the corpus is 200 DPI, so every scanned page lands there. If a compression figure on any site does not name a browser, it is describing one browser and not telling you which.
What a 100 MB job actually costs in time
On the same 15 August 2026 desktop run, Balanced on that 118.99 MB scan took 15.5 seconds in Chromium, 13.6 in Firefox and 13.4 in WebKit. Those wall times come from a headless browser with unthrottled animation timing — the friendliest this product will produce — and the same cell was separately seen ranging from 15.3 to 23.3 seconds run to run on an idle machine, so read them as a shape rather than a stopwatch. A 100-page 39.76 MB scan took 5.4 seconds in Chromium in the same run. The full per-engine tables live in the technical deep dive.
On a phone, by hand
Two real handsets were driven by the site’s author with a stopwatch on 13 August 2026, on bundles older than the desktop matrix measured. An iPhone 14 in Safari completed Balanced on that same 119 MB, 300-page scan in 30–40 seconds, with no white flash and no reload. An Android handset in Chrome completed the same job in 60–100 seconds — its model and Android version were never recorded, so it cannot even be classified, with no crash and no reload. Those bounds are coarse because a human eye produced them, and they are reproduced without being sharpened. No memory figure exists for either phone, or for any phone; desktop versus mobile sets out what those two rows do and do not license.
When Balanced is the wrong mode
Maximum re-renders each page as an image, which is the right tool for a photo-heavy scan and the wrong one for a text document. On the 100-page scan on 15 August 2026 it reached 0.195 in Chromium, 0.214 in Firefox and 0.299 in WebKit. On a document with almost nothing to rasterise it goes the other way: our 2-page government form grew 70% in Chromium under Maximum, and a 2.4 KB letter came back 25.1 times over in Chromium. The tool detects that and tells you to keep the original. Target-driven walkthroughs are in compress a PDF to 1MB, to 2MB and for email.
Check the result before you send it
Of the 124 runs on 15 August 2026, 79 produced an output document and 79 of 79 were reopened and checked in poppler — a PDF stack that shares no code with the one this site ships — for page count, a real page-1 raster and, where relevant, a surviving text layer. That check was external and afterwards, in our harness: the 33 individual tool pages do not verify themselves, and saying otherwise would be the easiest lie on this page. If you want the check on your own file, reopen the result in a different reader. If the file also needs to be combined first, Merge PDF and then compress; if it is a scan you also need to search, run OCR after compressing, not before. What changed and when is in the changelog.
Related
Processing a large PDF without uploading · Why browser PDF tools freeze · PDF Privacy Lab · All 43 tools
Frequently asked questions
How much smaller will my 100MB PDF get?
It depends on your browser, and that is a measured fact rather than a hedge. On 15 August 2026, on the same 118.99 MB 300-page scan at the same Balanced setting, Chromium delivered a 66% reduction, Firefox 61%, and WebKit — Safari's engine — 43%. Documents with no oversized photographs come out the same on all three, because that path is plain JavaScript.
Why does the same file compress differently in Chrome and Safari?
A photograph above 150 DPI for its page box is decoded, downsampled through a canvas and re-encoded by the browser's own JPEG encoder. Skia, Gecko and ImageIO do not produce the same bytes at the same nominal quality. Every scan in our 15 August 2026 corpus is 200 DPI, so every scanned page takes that route — which is why this site publishes no single 'compresses by X%' figure anywhere.
How long does a 100MB PDF take?
On 15 August 2026, on an Apple M4 desktop, Balanced on the 118.99 MB 300-page scan took 15.5 seconds in Chromium, 13.6 in Firefox and 13.4 in WebKit. Those are headless-browser wall times and are the friendliest this product will produce; the same operation was separately observed varying between 15.3 and 23.3 seconds run to run on an idle machine, so treat them as the shape rather than as a stopwatch.
Should I use Maximum instead?
Only on documents that are mostly photographs. Maximum re-renders pages as images, so on the same 100-page scan on 15 August 2026 it reached a ratio of 0.195 in Chromium, 0.214 in Firefox and 0.299 in WebKit. On a document with nothing to rasterise it makes the file bigger — on our 2-page government form it grew 70% in Chromium under Maximum — and the tool says so rather than reporting a win.