Why browser PDF tools freeze on large files

Updated 18 August 2026

The usual cause is not processor speed. It is how much of a document an operation insists on holding at once, plus a long wait before anything is painted. Our own editor left a 1,000-page file blank for 73.4 seconds in Chromium on 13 August 2026 while it built every page first; it now paints the first page at 1,027 milliseconds or less.

The measured cause is not a slow processor: it is how much of the document an operation holds, and how long it waits before painting anything.

1. Open the large document and start a timer. Note when the first page appears, not when the file finishes loading.
2. Scroll to the middle. Pages should render as you reach them rather than all having been built in advance.
3. Start a heavy operation and try the Stop button while it runs — a tool that cannot answer a click is the one that is genuinely stuck.
4. Read the progress text. A phase and a page counter is a real signal; a percentage with no counter behind it is not.
5. If it is slow rather than stuck, note which browser you are in before concluding anything — recognition timing in particular varies enormously.

The finding: it was never the processor

The intuitive model is that a big file means a lot of computation and a hot processor. That model is wrong twice over, and we published the measurement that falsified our own version of it. On 13 August 2026, in Chromium, page-image export was driven across a ten-fold input range: 2219 MB of peak process memory at 39.76 MB of input, and 2362 MB at 396.72 MB of input. Peak memory is nearly flat across that ten-fold range of input. The cost is a working set — how much of the document the operation insists on holding at once — not a multiple of the document’s size.

An early estimator encoded page-image export at roughly 55 times the input size, derived from a single small measurement, and would have predicted about 21,835 MB for a job that measured 2362 MB and finished in under two minutes. Shipped as written, it would have refused documents that work. The estimator was rebuilt around the measurement instead of the model.

The other half: nothing painted, for 73 seconds

The genuine freeze in this product was structural, and it was in the PDF Editor. It looped over every page building a canvas, and only rendered anything visible after the loop finished. On 13 August 2026, in Chromium, the first canvas with real pixels appeared at 9,036 ms on a 100-page scan, 22,074 ms on a 300-page scan and 73,394 ms on a 1,000-page document — exactly when the last page finished building, to the millisecond. The progress panel had already been dismissed, so there was no spinner, no percentage and no error: 73 seconds of blank white pages, indistinguishable from a hang.

After the fix, first paint stopped scaling with page count entirely. The same 1,000-page document painted its first page at 1,027 milliseconds or less, and the 15 August 2026 re-measurement at finer sampling read 517 ms or less in Chromium, 588 ms or less in Firefox and 516 ms or less in WebKit — the same half-second as on a one-page document. Both figures are upper bounds set by the sampling interval, not readings.

What keeps it bounded now

Pages are rendered as you reach them and released as you leave them. In standard mode a page starts rendering 300 pixels before it scrolls into view and is released 900 pixels after it leaves; the editor keeps three rendered pages around the one you are looking at, one in low-memory mode, and zeroes the backing store of every canvas it evicts. At most 200 thumbnails are rendered however long the document is, which is why Organize Pages cost 721 MB on 3,000 pages against 688 MB on 1,000 in the same Chromium run — the memory is bounded by the feature, not the page count. Page-image export was rebuilt as a render-encode-release pipeline and fell from 2219 MB to a 534–582 MB band on the same 100-page scan.

The thing we cannot test, said plainly

We have never produced a real allocation failure to test against. In 144 instrumented runs — 124 across three engines on 15 August 2026 and 20 in the Chromium matrix before them — nothing crashed, hung silently or ran out of memory at any size tested. An earlier step established that desktop browser command-line flags cannot manufacture one either. So the branch that handles allocation failure is proven only against injected errors, and the pre-flight check’s thresholds are uncalibrated. What the pre-flight does today is real and modest: it names the mode it picked before the run starts, and returns the verdict unknown — “no memory band has ever been measured on this device class” — for every device except the one desktop the benchmark ran on. Peak memory is also a poor thing to build a promise on: one cell repeated five times in Chromium read 684, 689, 627, 694 and 709 MB, and an independent four-run repeat of a different cell, a compress run in WebKit, spread 924–1681 MB with byte-identical output every time.

How to tell slow from stuck, in any tool

Look for a phase and a real counter, and try the Stop control. Slowness with truthful progress is not a freeze: OCR in Firefox takes roughly twelve times longer than in Chromium and was mistaken for a hang by our own harness before a control run corrected it. Stopping should end the run and leave your file untouched. The complete benchmark tables, all fourteen success criteria with the five that did not pass, and every absence are in how UnboundPDF handles large PDFs locally; processing a large PDF without uploading is the practical route, desktop versus mobile covers phones, a PDF that will not open covers the other failure people call freezing, and the changelog dates each change.

Related

Compressing a 100MB PDF locally · PDF Privacy Lab · All 43 tools

Frequently asked questions

Is a frozen PDF tool running out of memory?

Usually it is not, and in our own testing it never was. Across 144 instrumented runs — 124 on 15 August 2026 across three engines and 20 in an earlier Chromium matrix — not one run hit a genuine allocation failure at any size we tested. What we did find was a 73.4-second blank window in our editor on a 1,000-page document, which is indistinguishable from a hang and is not one.

Why does memory not grow with file size?

Because the cost is a working set — how much of the document an operation holds at once — rather than a multiple of the document. Driven across a ten-fold input range in Chromium on 13 August 2026, page-image export read 2219 MB at 39.76 MB of input and 2362 MB at 396.72 MB. Peak memory is nearly flat across a ten-fold range of input.

Can you detect a tab that is about to crash?

Not reliably, and we say so rather than implying otherwise. Nothing has ever crashed in our testing, so the pre-crash detector cannot be validated against a real crash — and an earlier step established that desktop browser flags cannot manufacture one. The logic exists and is unit-tested; its thresholds are uncalibrated. That verdict is published as UNPROVEN on the deep dive rather than quietly omitted.

How do I tell slow from stuck?

By the progress text and the Stop button. A truthful tool names its phase and counts real items — “Recognizing page 2 of 3” in the run we sampled — and answers a click while it works. In our 15 August 2026 measurement the longest a queued click waited, across three engines and the heaviest operations in the corpus, was 57 milliseconds. A tool that shows a moving bar and answers nothing is the one to worry about.