Shrink a PDF with hundreds of pages

A 380-page scan and a 25 MB inbox

Marek has to email his scanned doctoral thesis, dizertacka-scan.pdf: 380 pages, 190 MB, every page a photograph of paper. His supervisor's inbox refuses anything over 25 MB, and the faculty office wants the same file under 10 MB for the archive upload. One file, two ceilings, and no patience left for tools that choke on the upload first.

His file illustrates the one rule of long documents: page count decides the job, not megabytes. A 190 MB thesis of scanned pages is hundreds of separate rendering jobs when the last-resort method runs, while a 190 MB export with a dozen photo pages is routine work. So judge your document by its pages first. Past a few hundred pages, plan for a long run, prepare the tab as below, and accept that the first attempt teaches you what your machine can do rather than promising a result.

The good news is structural. There is no coded size cap in the tool, no upload queue, and no server gate that rejects big files, because the document never leaves the tab. The ceiling is whatever memory your device hands the browser, which makes a desktop the natural machine for this job and a phone the fallback.

Give the tab room to work

Five minutes of preparation decide whether a long run finishes or dies halfway. Walk this list before you press the button.

• Do the job on a desktop or laptop when you can. A phone tab gets a smaller memory budget, and a run that outgrows it simply stops, with no partial file kept.
• Close the other heavy tabs, especially video calls, maps and streaming. One heavy job per window is the rule.
• Never reload the page mid-run. The document lives in the tab's memory, so a reload throws the whole job away and the run starts again from zero.
• Keep the tab visible and the machine awake until the download lands. A sleeping laptop pauses the work along with everything else.
• Know your two ceilings before you start: the recipient's cap, and the fallback 10 MB target for archive-style uploads when nobody states one.

Run it in four moves

1. Open the large-file page in a fresh desktop tab.
2. Choose the PDF or drag it onto the page; it opens locally, with no upload step.
3. Type the recipient's cap as your target, in MB for long files, or leave the box for the fallback.
4. Press Compress, watch the progress bar with its time estimate, and read the verdict when it lands.

Expect a quiet middle stretch on long scans: page after page rendering one after another looks like nothing is happening. That is normal work, not a stuck tab. Give it time, and touch nothing until the verdict appears.

Read the verdict like a mechanic

The verdict reports three things: the finished size, the distance to your target, and the technique that did the most work. On a long file, the distance is the whole diagnosis. A small miss and a huge miss have completely different answers, so read the number before anything else.

A small miss, say 11 MB against a 10 MB cap, means the document nearly cooperates. Drop the pages nobody needs, a blank divider here, a duplicated appendix there, with the organize tool, and run the slimmer file again. The missing few percent usually come from pages, not settings.

A huge miss, say 60 MB against a 10 MB cap, means the document fundamentally resists. No second run at a lower number fixes a scan whose pages are mostly ink; the honest answers are splitting the file into parts that each fit, or asking whether the recipient accepts a shared folder link. The size breakdown shows which pages carry the weight, so the split cuts in the right places.

One guardrail holds on every run no matter the length. Candidates whose text count drops more than 2% against the source never reach you, which means an absurdly low target fails loudly instead of handing you a damaged thesis. Length never switches that check off: a 380-page run is verified the same way a four-page one is.

Long-file mistakes and recoveries

Starting on the phone. It sometimes works, and when it dies halfway there is no resume. Recovery: move the file to a desktop tab and run once. The phone guide covers what mobiles handle well and where they give up.

Typing a tenth of the current size first. Asking 190 MB to become 10 MB in one leap can work on photo reports and fail loudly on ink-heavy scans. Recovery: treat run one as reconnaissance, read the distance, then split or step the target.

Reloading during the quiet stretch. The progress bar barely moves while pages render, panic sets in, and the reload deletes the job. Recovery: there is none for that run, so start it again and walk away from the keyboard this time.

Splitting before trying. Cutting a manual into six parts that would have fit whole just makes six files to track. Recovery: compress first, split only what still misses.

Recompressing the download at the same target. Each pass removes the easy weight first, so a second run at the same ceiling finds nothing left to take. Recovery: change the plan, fewer pages or a split, instead of repeating the run.

When the browser is not the machine for it

Most long files finish fine in a tab. Three situations call for a different route. The first is a workplace that forbids opening documents outside approved software: policy beats convenience, so keep the file in the sanctioned app and ask IT how they shrink large PDFs.

The second is a file heading for professional print. A thesis that goes to a print shop wants its original resolution, and a compressed copy tuned for screens will fail preflight or print soft. Send the original and let the printer decide.

The third is the truly gigantic scan that dies in every tab you try. Before declaring defeat, ask the sender whether the source still exists: a scanner that produced the PDF can often re-export at lower resolution, and the general shrinking guide explains how to tell a scan from a text document, which decides everything downstream. When none of that applies, a desktop app with the whole machine's memory is the honest next step, not a seventeenth tab.