Compress large PDF files

What a browser tab is allowed to use

The engine runs inside the tab, so the tab's memory budget is the real ceiling, not any rule in the tool. The measured figure comes from an iPhone 16 Pro class phone with 8 GB of RAM on iOS 26.6: the tab was killed at a hard 2 GiB per-process cap, with 494 MB of system memory still free. That cap is device-class specific. A phone with 4 GB gets less, and nothing here measures how much less. Desktop browsers have more room and no measured ceiling of ours.

A second limit binds before memory does on any single page. A canvas tops out at 8192 by 8192 pixels, exactly 67,108,864 of them. One row more comes back blank with nothing reporting a failure. The largest page in the test corpus at 150 dpi is 9.9 million pixels, 15% of that cap, so ordinary pages are nowhere near it.

Page count is the number that matters

Megabytes are a bad predictor. A 60 MB file that is 12 pages of photographs is easy. A 30 MB file that is 900 scanned pages is the hard one, because the raster method walks every page.

That walk was measured. On the same phone, a 300 page run at 150 dpi finished all 300 pages in one tab without a kill, at a median of 671 ms a page, and the per-page cost drifted up only 17% across the whole run. So the memory does come back between pages. Nothing here measures a document past 300 pages.

How long it takes

On the 120 case public run the median compression took 2,512 ms and the ninetieth percentile 3,968 ms. The slowest single case took 9,119 ms, a mixed document aiming at a 1000 KB target where the raster method had to run. The whole 120 case run took 305 s.

Those are ordinary documents. A several hundred page scan is a different scale of job, and the honest answer is that no bench figure covers it. Expect the raster method to dominate the time, because it is the one that renders every page.

What to close before you start

Three habits stop a long run from failing halfway.

• Give the tab room. Close the other heavy tabs, especially anything holding video or a map, and do the job in a window with nothing else loaded. On a desktop that is usually enough for any document you are likely to have.
• Do not reload the page while it is working. The document lives in the tab memory and a reload throws it away, so a long run starts again from the beginning.
• Watch the reported size rather than the clock. The tool tells you the size it reached even when it missed your target, and on a long document that number is the useful signal. Being 5% over the limit and being 300% over have completely different answers.

When the file will not go small enough

Try the size first. The large file page and a 10 MB target both run the same engine, and on a scan the reduction is often dramatic: the top tenth of the public run gave back 88.1% of the source bytes.

If it still does not fit, split rather than squeeze. A 400 page manual sent as four 100 page files reaches the other end. The same manual crushed until it fits one mail attachment arrives unreadable. Organize pages cuts a document into parts without rebuilding it.

And check what is actually heavy before assuming compression is the answer. The general guide covers how to tell a scan from a text document in five seconds, which decides everything else. The compress hub lists the rest of the cluster.