Large PDFs on desktop vs mobile — what we measured
Updated 18 August 2026
Desktop is faster, and a phone is not excluded. On 15 August 2026 a 119 MB, 300-page scan compressed in 15.5 seconds in Chromium on an Apple M4 desktop. Run by hand on 13 August 2026, an iPhone 14 finished the same job in 30–40 seconds and an Android handset in 60–100 seconds, neither hitting a memory wall.
Both phones we tested finished the same 119MB job the desktop did, slower. The measured rows, the bounds, and everything nobody has instrumented.
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.
- Decide by patience rather than by capability: both devices finished our test job, at different speeds.
- On a phone, close other tabs first — several tabs at once is the one scenario nobody has measured.
- Open the tool and read the pre-flight panel: on an unrecognised device it says so instead of guessing.
- Start the run and leave the tab in the foreground while it works.
- Reopen the finished file in another reader before sending it — the tools do not verify their own output.
Ten hand-run phone rows and one instrumented desktop class is the entire device evidence base. This page reports both, with their bounds intact, and names what nobody has measured.
The same job, three devices
The single document tested on every device we have is a 300-page scan of 118.99 MB, compressed at the Balanced setting with Compress PDF. On an Apple M4 desktop on 15 August 2026 it took 15.5 seconds in Chromium, 13.6 in Firefox and 13.4 in WebKit. On an iPhone 14 in Safari on 13 August 2026 it completed in 30–40 seconds, with no white flash and no reload. On an Android handset in Chrome on the same day it completed in 60–100 seconds, with no crash and no reload. Neither phone hit a memory wall at that size.
The phone rows were driven by the site’s author by hand, with a stopwatch and a human eye, against the live site on bundles older than the one the desktop matrix measured. The bounds are coarse because the method was coarse, and they are reproduced here without being sharpened, averaged or merged into the desktop numbers. The desktop wall times, conversely, come from a headless browser with unthrottled animation timing — the friendliest this product will produce — so the real gap between the columns is narrower than dividing one by the other suggests.
What else the phones finished
Both handsets opened a 100-page, 40 MB scan in the editor — page 1 visible within 10–20 seconds on the iPhone 14 and 30–40 seconds on the Android handset — and both completed a page-image export of it with the ZIP download landing. Both also loaded a 1,000-page document, and both scrolled it badly: “like hanging” on the iPhone, “slow” on the Android handset’s bundle. That is the shape of the mobile result. The problems found on phones were interface and speed, not crashes. Step-by-step mobile workflows are in merge and compress on iPhone and on Android.
What is unknown, and it is a lot
No memory figure exists for any phone. Nothing was instrumented on either handset: no memory sampling, no per-phase timing, no output verification — those rows are what a person saw. That handset’s model and Android version were never recorded, so it cannot even be classified. iOS Safari’s desktop-class mode has never been tested, and WebKit on macOS is not a proxy for it. The current bundle has not been run on any phone. Neither has a mid-range laptop, which is the class most likely to actually struggle, and neither has the scenario in which people genuinely run out of memory: several tabs or several operations at once. All of those absences are listed on the technical deep dive rather than left to be inferred from silence.
Low-memory mode: what it does, and the claim we refuse
Low-memory mode is wired on seven of the 43 tools and does something different on each family. On the editor, Fill & Sign and Sign PDF it shrinks the rendered-page cache from three pages to one and clamps the canvas area budget from 16 to 4 megapixels. On Split, Organize and Rotate it narrows the thumbnail band so pages render only once they are on screen. On PDF to JPG it narrows that same band and halves the export batch — the page cache and the canvas clamp are read only by the editor.
We cannot tell you it reduces the risk of failure. That is a comparison against a failure rate, and the rate we have measured is zero: no failures in 124 runs on 15 August 2026 and none in the 20 before. There is no risk in our data for the mode to reduce, so its effect stays unclaimed until something fails. A browser reporting a small memory budget gets the mode and an unknown verdict, because a small budget is a signal we have nothing measured against.
Choosing, in practice
If you have a desktop and the file is large, use it. On the one job every device ran, it took 15.5 seconds in Chromium against 30–40 seconds on the iPhone 14 and 60–100 seconds on the Android handset — a factor of roughly two to two-and-a-half against the iPhone, and less than that in practice, because the desktop figure is a headless best case and the phone figures are stopwatch bounds. It is also the only device class with instrumented measurements behind it. If you only have a phone, our two rows say the work finishes; expect to wait, close other tabs, and expect scrolling a very long document to be unpleasant. Either way the file stays on the device, which is the part that does not change with hardware — verify it yourself with the PDF Privacy Lab. Practical routes are in processing a large PDF without uploading, compressing a 100MB PDF locally and stopping a run safely; combining files first is Merge PDF, and dated changes are in the changelog.
Related
Why browser PDF tools freeze · All 43 tools
Frequently asked questions
Can a phone handle a 119MB, 300-page PDF?
Both phones we tested did. On 13 August 2026 an iPhone 14 in Safari completed a Balanced compression of that document in 30–40 seconds, and an Android handset in Chrome — model and Android version never recorded — completed it in 60–100 seconds, neither with a crash, a reload or a memory-kill banner. Those are stopwatch bounds recorded by hand, on bundles older than the desktop matrix measured, and they are the only non-desktop results in existence.
How much faster is a desktop?
On the same 119 MB 300-page scan: 15.5 seconds in Chromium on an Apple M4 desktop on 15 August 2026, against 30–40 seconds on the iPhone 14 and 60–100 seconds on the Android handset on 13 August 2026. The desktop figures come from a headless browser with unthrottled animation timing and are the friendliest this product produces, so the real gap is narrower than the ratio suggests.
How much memory does a phone need?
No phone memory figure is published because none has been measured. What exists are hand-timed runs that completed — a 119 MB, 300-page scan compressed in 30–40 seconds on an iPhone 14 and in 60–100 seconds on a Mi phone — with no memory sampling. Before a large job starts, the tool checks the document against your device and tells you what it found. A phone memory requirement quoted elsewhere for browser PDF work is not a measurement of this product.
Does low-memory mode help on a phone?
The mode is real and we can tell you exactly what it changes, on ${word(LOWMEM_N)} of the ${TOOL_N} tools. What we cannot tell you is that it reduces the risk of failure, because that is a comparison against a failure rate and the failure rate we measured is zero — no failures in 124 runs on 15 August 2026, none in the 20 before. Its effect stays unclaimed until something actually fails.