Resource planning
Estimate browser memory before processing large files
A compressed file expands during decoding. One 12,000 by 8,000 RGBA image is about 384 MB before temporary canvases and encoded output; several PDF page renders can multiply that demand.
Workflow
Estimate the decoded workload
Multiply width by height by roughly four bytes per RGBA image, then account for source, destination, previews, PDF renders, and encoding buffers that may coexist.
Reduce concurrency and scope
Close memory-heavy tabs, process fewer files or pages, lower render DPI when appropriate, and prefer a current desktop browser for very large jobs.
Recover without corrupting work
If progress stops, cancel, wait for cleanup, reload if needed, and retry a smaller batch rather than repeatedly starting overlapping jobs.
Limits to understand
Browsers and devices do not expose a dependable universal memory ceiling. Mobile operating systems may terminate a tab without warning, and successful decoding does not guarantee enough memory remains for encoding and download.
Privacy mode
Processing smaller local batches does not change the no-upload boundary. Avoid moving to an unknown server converter merely to bypass memory limits when the document is sensitive.
Verify the result
Test a representative large file before a deadline, confirm cancellation releases previews and the next job succeeds, inspect every partial batch, and combine only verified outputs.
Frequently asked questions
Why does a 20 MB image need hundreds of MB?
The compressed bytes expand to a full pixel buffer, and processing may hold several buffers or canvases at once.
Will increasing browser storage help?
Usually not. Working memory and storage quota are different resources; these jobs intentionally do not persist source files in browser storage.