Compressing 100 photos at once: what actually happens in your browser
"Compress multiple images at once" is the feature that decides whether a browser tool is a toy or a real tool. Single-image handling is a demo. A media library is work. But there is a point where a browser genuinely stops being the right place to do the job, and understanding where that point is saves you from staring at a frozen tab wondering whether you did something wrong.
Nothing went wrong. You hit the ceiling. Here is what it is.
Batch work is a memory problem, not a speed problem
It is tempting to describe heavy image processing as slow. It usually is not. On a modern laptop, re-encoding a photo takes well under a second. The failure mode people actually hit is not sluggishness — it is the tab becoming unresponsive partway through and then being killed.
The reason is how images are held in memory. A compressed JPEG might be 3–4 MB on disk, but the moment a browser decodes it to draw it, it expands into a raw bitmap of width × height × 4 bytes. Do the arithmetic on a modern phone camera:
| Photo | On disk | Decoded in memory |
|---|---|---|
| 12 MP (4032 × 3024) | 3–4 MB | ~47 MB |
| 48 MP (8000 × 6000) | 15–18 MB | ~183 MB |
| Screenshot (1440 × 900) | ~0.5 MB | ~5 MB |
A batch of thirty phone photos therefore asks for well over a gigabyte of memory just to hold the decoded images at once, on top of the outputs being produced alongside them. A phone has a fraction of a laptop's headroom, which is why the same batch that works fine on a desktop quietly fails on a mobile browser.
What our compressor does, and where it stops
We run a batch by starting every file at once and collecting the outcomes as they finish, rather than stopping at the first error. That design choice has two visible consequences worth knowing about.
One bad file does not sink the batch. If one image is corrupt or in a format the browser cannot decode, it is reported individually and the rest still complete. You get a list of failures rather than an error dialog and no output. For a folder of photos dragged in from five different phones and cameras, that is the difference between a clean result and a lost afternoon.
There is no throttle — and that is a real limit. Because every file starts immediately, a very large batch asks for all its memory at the same time. Somewhere around 20–40 phone photos this stops being comfortable on a laptop, and considerably sooner on a phone or a low-memory tablet.
So how do you compress a lot of files anyway?
- Split the batch. Thirty files per run is a reasonable group size. Run it, download the zip, start again. This is the fix that works, and it is not a workaround — it is how you keep the memory ceiling from mattering.
- Resize first if you know the target size. Compressing a 12 MP photo to something it will never be displayed at wastes memory and time. If a form wants 600×600, resize first — the memory each file needs drops by roughly an order of magnitude before compression even begins.
- Target a size rather than a quality. If the reason you are compressing is a file-size limit, use the exact-size option. It searches for the highest quality that fits, instead of you guessing at a slider and repeating the run.
- Close other heavy tabs. This sounds trivial and it is not. A tab holding a video editor or a large document library competes for the same pool the batch needs.
- Take the zip. A batch comes back as a single archive rather than forty separate downloads, which saves you the part of the task people forget: the sorting.
When to stop using the browser entirely
There is a real point where the honest answer is that you need something else, and pretending otherwise wastes your time.
Use a browser tool for tens of files, one-off jobs, anything where privacy matters, and anything you want finished in the next five minutes. A product shoot where the images cannot go to a third party, a set of ID documents, a quick fix before an upload — this is exactly what a browser is good at, because there is nothing to install and nothing leaves your device.
Use a desktop tool or a build pipeline for hundreds of files, recurring jobs, or anything that has to be repeatable. This is not a quality judgement; it is a different architecture. A desktop application streams images from disk and releases each one after encoding, so its memory use stays roughly flat no matter how many files you feed it. A browser tab cannot discard images that easily, so its usage grows with the batch. For a one-time hundred-file cleanup, splitting into groups is fine. For a workflow you run every week, a script beats a web page — and if that script needs to be local too, Google's own encoder command-line tools are the standard answer, particularly now that the Squoosh command-line interface no longer exists.
The part worth taking away
If you remember one thing: browser batch compression fails on memory, not on time, and the countermeasure is splitting the batch rather than waiting longer or turning the quality down further. Lowering quality does reduce output size, but it does not meaningfully reduce the memory needed to produce it — the decode has already happened by then.
And if the reason you care about doing this locally is that the files are private, you can keep that no matter how many of them there are. The memory constraint is a property of the browser, not a trade-off we made for it. See why the tools run locally for the reasoning behind that decision.
Frequently asked questions
How many photos can I compress at once in a browser?
On a typical laptop, 20 to 40 photos from a phone camera is a comfortable batch. Phones handle fewer. The real limit is memory, not time: every image is decoded into an uncompressed bitmap roughly width multiplied by height multiplied by four bytes, so a single 12-megapixel photo occupies about 48 MB once decoded, before any output is produced.
Why did my browser freeze halfway through a big batch?
Because decoding an image expands it enormously and a browser tab has a memory ceiling. When a batch pushes past it, the tab either stalls waiting for the system to reclaim memory or it is discarded. Splitting the batch into smaller groups and running them one after another avoids both.
Is a desktop tool better than a browser tool for hundreds of images?
For a few hundred files on your own machine, yes. A desktop tool streams from disk rather than holding everything in tab memory, so it handles hundreds or thousands of files that would exhaust a browser. For tens of files, the browser is usually faster because there is nothing to install and no upload.
Should I resize before compressing a batch?
Yes, if you know the dimensions you need. Resizing first cuts both the memory each file requires and the compression work needed, so the whole batch finishes faster and finishes more often.