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. A tab that grows past what the device allows gets killed by the system, taking the run with it. That budget differs per device and per browser, and nothing here measures your exact number - a desktop tab usually has more room than a phone tab, and that is as precise as this guide gets.

The practical takeaway is order, not numbers: keep one heavy job per tab, and treat a phone as the weaker machine in every plan below. If a run dies halfway on mobile, the same file on a desktop tab is the first thing to try.

Page count is the number that matters

Megabytes are a bad predictor. A dozen photo pages in a small file is routine work. Hundreds of scanned pages in a mid-size file is the hard job, because the raster reserve walks every page. Judge the document by its page count first, its megabytes second.

The raster reserve is guarded: it starts only when the text arms missed the target, and then it renders page after page, which is why long scans take long. Nothing here measures a document past a few dozen pages - the pilot behind the parent page ran 19 compressions on 10 locally built documents in September 2026 at the default setting - so treat every large run as uncharted for your machine until it finishes once.

How long it takes

There is no honest number for this. Small documents finish while you watch the bar fill once; a several hundred page scan is a different scale of job, and no bench figure here covers it. The only timing clue is structural: the raster reserve renders every page, so on a long scan expect it to take most of the time whenever it runs.

Do not read speed as progress either. A quiet middle stretch usually means pages rendering one after another, not a stuck tab. Give it time before you touch anything - reloading throws the run away, as the next section explains.

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 the most room you can give it without touching any setting.
• 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.

What the well-known tools promise

The ranking pages for this query mostly sell the same three things: a size cap, a strength setting, and no installation. Adobe's online compressor page advertises files up to 2 GB; Smallpdf offers three named strengths - Basic, Moderate and Strong - with the two stronger ones behind its Pro plan; PDF24 stresses that its compressor is free. Those are their pages' claims, not measurements made here, and all three process your document on their servers after an upload.

The contrast on this site is architectural, not numerical. There is no cap coded into the tool and no strength switch, because the engine does not pick from three presets: you type the target number and it chases that number directly. And since the document never leaves the tab, there is no upload queue, no server-side size gate, and no waiting behind other people's files. The price of that design is the one this whole guide is about: your tab's memory is the only ceiling, and long runs ask for patience rather than a bigger plan.

Picking the target on a long file

On a short document any reasonable number works first try. On a long one, the target you type is the single decision that matters, so give it thirty seconds of thought. A round number far below the current size - a tenth of it, say - asks every page to give up most of its weight at once. That can work on photo-heavy reports, and it can also land far above the number on scans whose pages are mostly ink. The engine reports the size it reached even when it misses, so the first run is reconnaissance: read the distance, then decide whether the answer is a lower target, a split, or accepting the size you got.

One guardrail applies no matter what number you type. Candidates whose text count drops more than 2% of non-space characters against the source never reach you, which means an absurdly low target fails loudly instead of silently handing you a damaged file. Length alone never switches that check off - a 400 page run is verified page by page the same way a 4 page one is. If the verdict says the text check rejected candidates, the target was below what the document can honestly give, not a sign to try the same number again.

Four moves on a long file

1. Open the large file page.
2. Choose the PDF or drag it onto the page; it opens locally in the tab.
3. Type your target number, or leave the box for the fallback.
4. Press Compress, then read the verdict: final size, distance to target, winning method.

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. If the verdict comes back above your number, read the distance before anything else: a small miss and a huge miss have completely different answers.

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 small attachment can arrive hard to read. Organize pages cuts a document into parts.

And check what is actually heavy before assuming compression is the answer. Size breakdown shows which pages carry the weight, and the general guide covers how to tell a scan from a text document, which decides everything else. The compress hub lists the rest of the cluster.