Browser memory limits when processing files
My file is only 15 MB. Why did the tab run out of memory?
The file on disk is the compressed version
This is the whole misunderstanding in one sentence: the number you see in the file manager is the size of the compressed data, and nothing can be processed while it is compressed. To resize, recompress, convert or analyse an image, it has to be decoded into raw pixels first, and raw pixels are enormous.
The arithmetic is simple. A pixel in memory is normally four bytes — red, green, blue and alpha. A 4000 × 3000 photograph is twelve million pixels, so the decoded bitmap is about 48 MB. The JPEG it came from might have been 4 MB. The file grew by a factor of twelve before any work began.
| Dimensions | Pixels | Decoded bitmap |
|---|---|---|
| 1920 × 1080 | 2.1 million | about 8 MB |
| 4000 × 3000 | 12 million | about 48 MB |
| 6000 × 4000 | 24 million | about 96 MB |
| 10000 × 10000 | 100 million | about 400 MB |
And one copy is never enough
A realistic pipeline holds several copies at once: the compressed input bytes, the decoded source bitmap, an output bitmap at the new dimensions, the encoder's internal buffers, and the compressed result. A tool that also shows you a preview holds another. For the 4000 × 3000 photograph above, a peak working set of two to three hundred megabytes is entirely ordinary, for a file that looked like 4 MB.
PDF rasterisation behaves the same way, page by page: an A4 page rendered at 300 DPI is roughly 2480 × 3508 pixels, about 35 MB decoded, and a tool that renders several pages at once multiplies that. Video is worse again, because a decoder needs several reference frames resident at the same time.
Where the actual ceilings are
- A tab's memory budget is set by the browser, not by the site, and it is smaller than the machine's installed memory. It also shrinks when other tabs are busy.
- WebAssembly modules built for the common 32-bit memory model can address at most four gibibytes, and browsers often permit considerably less than that per instance.
- Individual buffers have their own maximum length, which is well below the total memory a page may use.
- Mobile operating systems terminate a tab that grows too large, with no warning and no error the page can catch.
- Graphics memory is a separate, smaller pool. A canvas larger than the platform's maximum dimension simply fails, however much system memory is free.
None of these are published as a single number you can look up, because they depend on the browser, the version, the device and what else is running. That is the real difficulty: a tool cannot ask how much memory it may use.
Why phones are the strict case
Phones have less physical memory, no swap in the desktop sense, and an operating system that is aggressive about reclaiming it from background processes. A browser tab is a background process the moment you answer a message. Mobile browsers therefore hold tighter budgets and are quicker to discard a tab, and the discard usually looks to you like the page reloading and losing your work rather than like an error.
The practical consequence is that a job which finishes on a laptop can be impossible on a phone with the same file. That is not a defect in the tool. It is a hardware boundary, and the honest response is to say so before starting rather than to crash halfway through.
How a careful tool behaves
- It estimates the working set from the decoded dimensions before it allocates anything, and refuses a job that clearly will not fit.
- It processes one file at a time on a constrained device instead of running a batch in parallel.
- It transfers buffers between the page and its workers rather than copying them, so a large file does not exist twice.
- It releases each result as soon as it is written, and revokes the temporary URLs that would otherwise keep the data alive.
- It streams page by page or frame by frame where the format allows, instead of loading an entire document into memory.
- It caps the pixel count it will accept, which is also what stops a small file that expands to an enormous canvas from taking the tab down.
What you can do when a job fails
- Close other tabs. They are competing for the same budget, and browsers do not share it fairly.
- Process fewer files at once. A queue of one is slower and far more likely to finish.
- Reduce the dimensions first. Halving the longest edge quarters the working set, and it is often what you wanted anyway.
- Split a large PDF and process the parts.
- Move to a desktop machine for the largest jobs. This is not a failure of local processing; it is the correct use of the hardware you have.
- Restart the browser if a tab has been open for days. Long-lived tabs accumulate memory that a reload releases.
The limit of any estimate
Browsers expose only a coarse hint about available memory, and some expose nothing at all. Any figure a local tool shows you is therefore an estimate built from the file's own dimensions and a conservative model of the pipeline, not a reading from the operating system. It is useful for deciding whether to attempt a job. It is not a promise that the job will complete, because the deciding factor — what the rest of the device is doing in the next thirty seconds — is not something a web page can see.
Tools for this
Sources
- W3C — WebAssembly Core Specification, memory model
- W3C — Device Memory API, and why the value is coarse
- WHATWG — HTML Standard, transferable objects