The size of a file on disk describes its encoded input, not the memory required to process it. Decoded content, algorithm workspace, output and preview resources can overlap. Device pressure and browser implementation limits also matter. Locate the failing stage before deciding whether to reduce dimensions, limit concurrency or move the workload.
A small JPEG can require hundreds of megabytes
A 6000 × 4000 image represented as ordinary 8-bit RGBA needs 96,000,000 bytes, about 91.6 MiB, for one pixel surface. If a decoded image, Canvas and getImageData result each retain a surface, that is about 274.7 MiB before input, encoder workspace, output and browser overhead. This is a capacity estimate: implementations may share storage or allocate additional surfaces.
| Input | Estimate | Important boundary |
|---|---|---|
| Image | Width × height × bytes per pixel × live surfaces | Lower JPEG quality does not reduce source pixel count |
| Audio | Sample rate × seconds × channels × bytes per sample | 10 min, 48 kHz stereo Float32 is about 219.7 MiB |
| ZIP | Actual expanded bytes, entries and concurrency | Compressed size is not an expansion bound |
| JSON | Text, object graph, output and rendered nodes | Structure affects memory as well as text size |
Halving both dimensions quarters the destination pixel count. But a codec that first decodes the complete source can still hit the original peak before resizing. Source-dimension limits and output-dimension controls solve different parts of the problem.
Distinguish crashes, stalls and leaks
| Symptom | Possible cause | First check |
|---|---|---|
| First run exits the tab | Excessive peak, codec failure or system termination | Input dimensions and failing stage |
| UI freezes then recovers | Main-thread long task | Performance trace and call stack |
| Failure after repeated runs | Retained results or leaked resources | Post-cleanup baseline over multiple cycles |
| Low JS heap, high process memory | Native, pixel, GPU or WASM allocations | Resource lifetimes and process metrics |
There is no universal file-size threshold that applies to every browser. Available system memory, background policies, other tabs, allocation constraints and Canvas limits can change the outcome. JavaScript error handling catches some failures, but cannot reliably catch the operating system terminating a renderer.
Reproduce the failure by stage
- Fix one input and record its bytes, dimensions or duration, browser and device. Run one task first.
- Mark reading, decoding, transforming, encoding and preview creation so the last completed stage is visible.
- Observe process memory and use Performance traces for stalls; compare heap snapshots when investigating retained JavaScript objects.
- Repeat processing and clearing ten times, then independently reduce dimensions, duration or concurrency.
- Retest cancellation, corrupt inputs and retries on a lower-memory target device.
Retaining paths can identify state, closures or listeners that keep an object alive. Taking snapshots also costs memory, so avoid repeatedly profiling a workload already at its limit. Objects inspected in a console can remain reachable through developer tools; repeat the user flow with tools closed as a cross-check.
Budget for workload rather than encoded bytes
Use pixel limits for images, duration and channel limits for audio, and entry-count plus per-entry and total expanded-byte limits for archives. Enforce decompression limits while bytes are produced rather than trusting declared sizes. A tiny hostile archive can generate far more output than its input suggests.
A planning model is baseline plus active tasks times their working set, plus retained results and a margin. If a measured task adds 250 MiB, four overlapping tasks may approach an extra GiB. Measure actual overlap rather than treating this as a fixed law. Reduce concurrency and retained outputs before simply moving the same allocations to a Worker.
Help users finish the job
Closing unused tabs may free resources but does not change the minimum working set of this task. Split batches, resize source images, trim audio and disable unnecessary previews. If one input remains too large, use software designed for that workload. Keep the original and avoid repeated retries in a page already retaining previous results.