How to OCR a large scanned PDF without freezing
Updated 18 August 2026
Open OCR PDF, choose the document’s language and start. Recognition runs page by page in your browser behind a live counter and a Stop button. On 15 August 2026 a 100-page, 39.76 MB scan finished in 94.2 seconds in Chromium and 88.9 in WebKit; Firefox took 1,179.3 seconds on the same file and produced the same text.
Make a 100-page scan searchable in your browser — with the measured per-browser timings, the live page counter, and how far off Firefox is.
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 OCR PDF and drop in the scan. Nothing is uploaded — only the recognition engine is fetched, once.
- Pick the document's language from the seven available. The right language is the single biggest lever on accuracy.
- Start recognition and watch the counter: it names the page it is working on — “Recognizing page 2 of 3” in the run we sampled — backed by a real count rather than a guessed bar.
- Leave the tab open. If it is taking longer than you expected, check which browser you are in before assuming it has hung.
- Press Stop at any point — it ends after the current page finishes, and your original scan is unchanged.
The scan stays in your browser. Only the recognition engine is fetched, once, and cached afterwards. Every timing below names its browser, its date and the document it was measured on.
The measured numbers, and the one that surprised us
On 15 August 2026, a 100-page scanned document of 39.76 MB was put through OCR PDF on three browser engines on one Apple M4 desktop. Chromium finished in 94.2 seconds, 0.94 seconds a page. WebKit finished in 88.9 seconds, 0.89 a page. Firefox took 1,179.3 seconds — 19.7 minutes, 11.8 seconds a page — for the same file, and produced a valid 100-page searchable PDF containing byte-for-byte the same 91,127 recognised characters as Chromium.
We recorded that Firefox cell as a hang first, and published the correction rather than the first answer. A three-page control settled it — 36.4 seconds in Firefox against 4.1 seconds in Chromium on the same file — and sampling the progress through the run showed the product telling the truth at every point: a per-page counter, a bar driven by that counter, and an enabled Stop button. Roughly twelve times slower is a real finding. A hang would have been a false one.
Why it does not feel frozen, measured rather than asserted
Long recognition runs look alarming, so the responsiveness was measured directly instead of being reasoned about. A self-rescheduling timer recorded the longest stretch in which a queued task — your click on Stop — could not run. Across three engines and the three heaviest operations in the corpus on 15 August 2026, the worst figure anywhere was 57 milliseconds. During Firefox’s 18.5-minute recognition grind, sampled 51,226 times, the worst was 30 milliseconds: the run most likely to look frozen is the one where the Stop button was most reliably answerable.
Two bounds on that, because the first instrument we built was wrong and the second one is not universal. It is desktop only, on three operation classes only, and it measures queued-task lag rather than frame timing — the paint meter that would have measured visual smoothness distorted its own subject by 26 times and was discarded, so nothing here claims smoothness. On phones the opposite was observed by hand: scrolling a 1,000-page document was described as “like hanging”. The full method is in the technical deep dive.
The engine download, stated exactly
Recognition needs a recognition engine, and that is the one thing this tool fetches. It is about 14 MB, downloaded from UnboundPDF on first use and cached by your browser afterwards, so only the first run needs a connection. Your document image is not part of that exchange and never leaves the tab. The method for verifying that yourself, in a browser you control, is in the PDF Privacy Lab.
Stopping, and what a stop costs you
OCR is one of seven tools whose Stop label reads “it stops after the current page finishes” rather than “within the current item”, because recognition of a page is not interruptible half-way. Stopping ends the run and leaves your scan unchanged — “Stopped. Nothing was saved and your original file is unchanged.” Nothing resumes: all 43 tools are recorded as restart-required, and stopping at page 90 of 100 means starting again rather than continuing. Cancelling a PDF operation safely covers which tools behave which way.
Getting a good result from a big scan
Accuracy comes from the scan, not the engine: clear, straight, high-resolution pages in the selected language recognise well, and blurry or skewed ones do not — why a PDF looks blurry covers the input side. Compress after recognising rather than before if you care about the text layer, using Compress PDF; a Chinese-language document in our corpus kept 2,988 characters through a re-save on 15 August 2026, so the layer does survive, but there is no reason to test it unnecessarily. General scanned-document workflow is in OCR a scanned PDF and editing scanned PDF text; recognizing a scan in a specific non-English language is covered in OCR a PDF in Vietnamese, Polish or Turkish; broader large-document behaviour is in processing a large PDF without uploading, and dated changes are in the changelog.
Related
Why browser PDF tools freeze · Desktop vs mobile · All 43 tools
Frequently asked questions
How long does OCR take on a 100-page scan?
On 15 August 2026, on an Apple M4 desktop: 94.2 seconds in Chromium (0.94 s per page), 88.9 seconds in WebKit (0.89 s per page) and 1,179.3 seconds in Firefox (11.8 s per page) on the same 39.76 MB scan. All three produced a valid 100-page searchable PDF; Chromium and Firefox extracted byte-for-byte the same 91,127 characters and WebKit 91,464.
Why is OCR so much slower in Firefox?
We do not have the mechanism, and we will not invent one — what we have is the measurement. We first recorded that cell as a hang and were wrong. A three-page control settled it: 36.4 seconds in Firefox against 4.1 in Chromium for the same file, with a per-page counter, a bar driven by that counter and a live Stop button at every sample. Firefox is roughly twelve times slower at recognition, not stuck.
Does my scan get uploaded for recognition?
No. Recognition runs in the tab. The engine itself — about 14 MB — is downloaded from UnboundPDF the first time you use OCR and then cached by your browser, so only the first run needs a connection. The document image never leaves your device.
Will the page freeze while it recognises?
It did not in the measurement. During the heaviest operations in the corpus, a timer measured the longest stretch in which a queued task — your own click on Stop — could not run. The worst figure anywhere across three engines was 57 milliseconds, and during Firefox's 18.5-minute recognition grind, sampled 51,226 times, it was 30 milliseconds. That is desktop only, and it measures queued-task lag rather than visual smoothness.