Large file jobs on mobile usually fail because of memory pressure and computation, not network speed. Selecting a 300MB file does not limit memory use to 300MB: the input bytes, decoded representation, intermediate canvas or engine memory, and output may coexist for part of the job.
A progress indicator that pauses, a page that stops responding to touch, and a tab that reloads or closes without an error are different symptoms. Instead of repeatedly retrying the same workload, first identify the likely stage and reduce the amount processed at once.
Concurrent data matters more than the source size alone
Expanded pixels, working copies, intermediate results, and the finished output can require far more memory than the compressed source.
Long computation can delay progress updates and touch response even when the underlying operation has not failed.
Reduce page count, image count, output dimensions, and the number of results held before packaging.
Narrow down the failure in five steps
- 1
Try a smaller file of the same format or fewer pages first. If it succeeds, memory or workload is more likely than unsupported input.
- 2
Close other tabs and memory-heavy apps, reopen the browser, and retry once. Avoid repeated attempts in the same tab after a failure.
- 3
Lower output dimensions or quality for images and PDFs, and split a batch or page range in half.
- 4
If mobile still fails, run the same source in a desktop browser with more memory to distinguish a damaged file from a device limit.
- 5
Record the message, stage, format, source size, and page or image count. The point of failure is more useful than a generic ‘it did not work.’
Why a 300MB file can require much more than 300MB of memory
When the browser reads a file, it first creates a continuous block of working data called an ArrayBuffer. A WebAssembly engine—the technology that runs conversion code inside the browser—or a compression library may copy that data into its own workspace, while the source and output remain alive for part of the operation.
For images, decoded pixel count matters more than compressed size. A 4000×3000 image contains 12 million pixels; one simple RGBA buffer is about 48MB. A canvas, resize intermediate, and output Blob can overlap, so a small JPG may still create a large working set.
Different jobs multiply memory in different places
One source-size limit cannot describe every workload. The same 100MB input can behave very differently depending on decoding and the number of outputs retained.
| Job | Additional data | Reduce the load |
|---|---|---|
| Image compression or conversion | Decoded pixels, canvas, output Blob | Lower dimensions and batch count |
| PDF to images | Render canvas, page images, ZIP | Split page ranges and lower scale |
| Images to PDF | Multiple decoded images and PDF data | Use smaller batches and lower quality |
| Audio or video | Input copy, Wasm memory, decode, output | Split long sources or use desktop |
| Batch ZIP download | Individual outputs, compressed data, final ZIP | Download several smaller groups |
A stalled progress bar is different from a terminated tab
Much JavaScript work shares the main thread—the browser's primary path for updating the screen and handling input. A long computation can delay progress updates and touch response while the job continues. web.dev defines tasks over 50ms as long tasks and recommends breaking work into smaller pieces so rendering and input get opportunities to run.
A tab that reloads or is terminated without an application error points more strongly toward memory pressure or operating-system resource recovery. A web app cannot reliably know the usable memory of every phone, so a published maximum is not a guarantee that every device can finish that workload.
How to split work effectively
For PDF conversion, reduce page range and output scale before focusing only on the PDF file size. Rendering 100 pages as 2× PNG and retaining them for one ZIP can be far heavier than converting 10–20 pages at a time or starting with 1× JPG.
For image batches, consider both count and dimensions. High-resolution PNG outputs can use large decoded buffers even when the original HEIC or JPG total looks modest. Long audio and video transcoding keeps CPU and engine memory busy for longer, making smaller segments or a desktop browser the more reliable option.
- Reload before retrying so temporary data from the previous attempt can be released.
- Try JPG or WEBP instead of PNG, or 1× instead of 2× output, to reduce result size.
- If half the batch succeeds, keep future groups at or below that size on the device.
- Thermal throttling and battery-saving modes can also slow long jobs; let the device cool before another attempt.
Official documentation used for this analysis
Use a stable working size, not the published maximum, as your limit
Local browser processing avoids uploading file contents, but the visitor’s device must provide the computation and memory. A limit such as 150 pages is an input ceiling, not a promise that every phone can finish the largest allowed job.
Confirm support with a small sample, then increase page count, batch size, and output resolution gradually. If the same source works on desktop but fails only on mobile, consider device resources before concluding that the file itself is invalid.