How to process a large PDF without uploading it
Updated 18 August 2026
Open the file directly in an UnboundPDF tool — it is read into your browser tab and processed there, so no copy is sent anywhere. On 15 August 2026 a 300-page, 119 MB scan compressed, merged, exported and opened in Chromium, Firefox and WebKit, and both test phones finished the same compression by hand.
Open, compress, merge and export a large PDF in your browser without uploading it — with the documents we actually watched finish.
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.
- Pick the tool for the job — PDF Editor to read and change pages, Compress PDF to shrink, Merge PDF to combine, OCR PDF to make a scan searchable.
- Drop the file in. It is read into the browser tab, and no copy is sent to UnboundPDF.
- Read the panel before you start: it names the execution mode it picked for your device, and says plainly when it has never measured a device like yours.
- Watch the phase and the page counter while it runs — a real counter rather than a guessed percentage.
- Press Stop if you change your mind. The run ends and the file you opened is unchanged.
Nothing is uploaded. The document is read into your browser’s memory and the result downloads from the same tab. Every figure on this page names the browser, the date and the document it came from.
What “large” meant when we measured it
“Large” is a word most PDF sites use without defining it, so here is ours, as documents rather than as a promise. On 15 August 2026, on one Apple M4 desktop driving the real interface through three browser engines, these finished: a 300-page scanned document of 118.99 MB compressed, merged, exported to page images and opened in the editor on Chromium, Firefox and WebKit; a 500-page mixed document of 99.6 MB did the same; a 1,000-page document opened, merged and exported. In an earlier Chromium-only matrix on 13 August 2026, a 397 MB, 1,000-page scan and a 635 MB merge of 1,600 pages also completed.
Those are operating points we watched an operation finish. They are not a boundary, because we never reached one: 124 runs on 15 August 2026 and 20 before them all completed or refused cleanly with a named reason. The full tables, per engine and per operation, are in how UnboundPDF handles large PDFs locally, together with every measurement that failed to produce a finding.
Read the pre-flight panel before you start
Before a heavy run begins, the tool looks at the page count, the byte size, the kind of operation and whatever the browser will say about your device, then picks one of five execution modes: standard, low-memory, selected pages, desktop recommended, and one that stops before it starts — where the operation cannot produce a valid file, the tool refuses instead of running, in its own words: “we are stopping before it starts. Your file has not been changed.” It names the mode and the reason first, not afterwards.
Memory has been measured on exactly one class of machine — the desktop the benchmark ran on. Anything else gets the verdict unknown, in those words: “no memory band has ever been measured on this device class.” No memory quantity is ever shown to you, because on every device but one there is none to show.
Pick the tool by the job
Shrinking a scan is Compress PDF, and the result depends on which browser you are in — see compressing a 100 MB PDF locally for the measured split. Combining files is Merge PDF, which on 15 August 2026 took 2.4 seconds in Chromium to produce a 301-page document from that 300-page scan. Making a scan searchable is OCR PDF, the slowest operation here by a wide margin and the one with the most browser-dependent timing — OCR a large scanned PDF without freezing has the numbers. Turning pages into images is PDF to JPG, and reordering or removing them is Organize Pages or Split PDF, both of which render at most 200 thumbnails however long the document is.
Reading and changing a long document is the PDF Editor, and it is where the biggest measured improvement in this programme landed. It used to build a canvas for every page before painting any of them, so a 1,000-page file sat blank for 73.4 seconds in Chromium on 13 August 2026. It now paints its first page at 517 ms or less in Chromium on that same 1,000-page document, measured 15 August 2026 — why browser PDF tools freeze on large files explains what that bug actually was, and why it was not a memory problem.
You can stop, and stopping is safe
Every long operation carries a Stop control whose label says what stopping means for that operation rather than making one vague promise. Stopping ends the run, releases what it allocated and leaves the document you opened untouched — the message reads “Stopped. Nothing was saved and your original file is unchanged.” Nothing resumes anywhere in the product, and no page claims otherwise; cancelling a PDF operation safely sets out exactly which tools stop where.
Desktop, phone, and what is still unknown
A desktop is faster and a phone is not excluded: both handsets tested by hand on 13 August 2026 completed the same 119 MB compression, in coarse stopwatch bounds. Large PDFs on desktop versus mobile puts the two side by side, including what nobody has measured. And a good deal is unmeasured: no mid-range laptop, no identified Android model, no instrumented phone run of any kind, no second tab running at the same time, and no genuine allocation failure in 144 instrumented runs — so the code path that would handle one has only ever been tested against injected errors. Those absences are listed in full on the deep dive above, and what changed and when is in the changelog.
Related
PDF Privacy Lab · All 43 tools
Frequently asked questions
How large a PDF have you actually seen finish in a browser?
On 15 August 2026, on one Apple M4 desktop: a 300-page 119 MB scan compressed, merged, exported to page images and opened in the editor on Chromium, Firefox and WebKit; a 500-page 99.6 MB mixed document did the same; a 1,000-page document opened, merged and exported. On 13 August 2026, in Chromium, a 397 MB 1,000-page scan and a 635 MB 1,600-page merge both completed. Those are documents we watched operations finish — not a point at which anything stopped, because nothing stopped.
Why won’t you tell me the largest file the tools accept?
Because we have never found one. Across 124 measured runs on 15 August 2026 and 20 in an earlier matrix, every run either completed or refused cleanly with a named reason, at every size we tested on every engine. No boundary was located, so publishing one would be an invention. What we publish instead is the largest document each operation was measured finishing.
Does anything get uploaded if my device is slow?
No. Two separate things are true here, and they are worth keeping separate. By design, the core tools have no upload endpoint. By measurement, a gate suite kills the HTTP server outright, reloads Merge PDF from cache, merges two real PDFs offline, then byte-scans every cache entry for a needle taken from the middle of each input — and no byte of either document appears in any entry. The first is architecture; the second is what was observed on the runs we made. The Privacy Lab shows you how to run that observation yourself.
Will a large PDF work on my phone?
Two phones were driven by hand on 13 August 2026, on older bundles than the desktop matrix measured: an iPhone 14 in Safari and an Android handset in Chrome — whose model and Android version were never recorded — both completed a Balanced compression of the same 119 MB, 300-page scan, in 30–40 seconds and 60–100 seconds respectively. Those are stopwatch bounds, and they are the only non-desktop results that exist — nothing has been measured on any other phone.