A browser tool can work locally and still run out of memory. The file's size on disk is only one part of the job. Decoding it, holding previews, passing data into an engine, and producing an output can need several representations at once.
That's why “this file is only a few megabytes” doesn't tell you whether a phone or an older computer can handle it.
Compare stored size with decoded size
The small solid PNG is 1,200 by 800 pixels and 5,688 bytes. The large one is 4,000 by 3,000 and 52,427 bytes. Both are a single flat color, which makes them unusually easy to compress.
Open the larger sample in Image Optimizer. The stored size is small, but the browser still decodes all 12 million pixels. At four bytes per pixel, one RGBA representation alone needs 48,000,000 bytes, about 45.8 MiB. The smaller sample needs 3,840,000 bytes for the same representation.
Those numbers are arithmetic from the dimensions and pixel format, not measurements of total browser RAM. Decoding, canvas storage, previews, encoding, and the browser itself can add more. The large sample's dimensions are from Chromium 146 on a Windows desktop. That isn't a speed benchmark, and it doesn't mean every phone can handle it.
A detailed photo usually compresses to a larger file than this flat-color example, but at the same dimensions its decoded pixel grid is the same size. Compression ratio and working image size answer different questions.
The first run has another cost
Some tools use browser APIs directly. Others load an engine such as FFmpeg, PDF rendering code, or an image decoder when the feature needs it. So the first run can spend time downloading and starting that code before it gets to your file.
Your file can stay on your device while that code comes over the network. “Local file processing” doesn't mean the page never makes a request. A cached second attempt may start sooner, but it still needs the same memory for the input and result.
Watch the tool's status to see what it's doing. If it says the engine is loading, selecting the same large file again won't speed that up. A slow download and a slow encode are different problems.
Video work adds time as well as memory
Use Media Info to check the duration, dimensions, codec, and other details before choosing an operation. A long high-resolution recording is a lot more work than a short clip, even when both have the same extension.
Video Optimizer re-encodes to H.264 MP4. It uses the encoder's slow preset, so a render can take longer than a metadata read or stream copy. Its CRF setting targets quality, not a processing deadline or an exact output size. Raising CRF won't reliably fix browser memory pressure.
The tool doesn't have a file-size limit that guarantees every accepted file will process. Browser limits, decoding support, available memory, and the recording itself all matter. The file picker accepting the extension is only the first step.
Reduce the work that doesn't need doing
Try a short representative clip before processing a whole recording. Check that the sound, picture, and downloaded file work where you need them. Close other heavy tabs if the machine is struggling, and don't run several tools on the same large file at once.
If you only need a few seconds, cut that part out first. If the output can have a smaller frame, reduce the dimensions with the right tool. The video size guide covers duration, dimensions, and compression as separate choices.
Check each extra re-encode too. Keep the original, and don't use your last heavily compressed experiment as the source for every new attempt.
Know when a desktop workflow is more practical
For a long recording, a large image set, or repeated failures on the same input, a desktop app can be the more practical place to finish. It gives you a different processing environment and doesn't tie the whole job to the memory available in one browser session.
There's no rule like “anything below 500 MB will work.” Start with a representative sample, read the status, and check the output. If the browser keeps failing before it produces a usable copy, change the workflow instead of retrying the same file over and over.