Batch Compress Images Online Without Uploading Them
Batch compression runs each image through the same target-KB encoder, queued in order, entirely on your device. Measured per-image encode times: 33 ms for an 800x600 JPEG, 84 ms for a 1920x1280 PNG, 123 ms for a 1920x1280 JPEG. A 50-image batch therefore completes in seconds, not minutes.
Measured Data
| Case | Source | Output | Deviation | Passes | Encode time |
|---|---|---|---|---|---|
| 800x600 JPEG to 50 KB | 55.4 KB | 45.7 KB | -4.3 KB | 8 | 33 ms |
| 1920x1280 PNG to 200 KB | 2673.4 KB | 196.8 KB | -3.2 KB | 8 | 84 ms |
| 1920x1280 JPEG to 100 KB | 232.1 KB | 93.5 KB | -6.5 KB | 8 | 123 ms |
| 1920x1280 WebP to 100 KB | 100.3 KB | 84.2 KB | -15.8 KB | 8 | 1266 ms |
What "Batch" Actually Changes
Compressing fifty images one at a time and compressing fifty images in a batch does the same amount of encoding work. The difference is everything around the encoding:
| One at a time | Batch | |
|---|---|---|
| Clicks required | 3 per image (150 total) | 3 once |
| Network transfer | 0 | 0 |
| Files held in memory | 1 | 1 (queued, not parallel) |
| Failure mode | you notice immediately | one bad file, queue continues |
| Naming | manual | automatic suffix |
The last two rows are the real argument. A queue tells you which files failed instead of silently leaving you with a folder of mixed results, and the automatic suffix means you never overwrite an original with a compressed copy.
The Measurements
Each image is encoded to a KB ceiling using the same binary search the single-file tool uses — eight passes over the quality range (or the scale range for PNG):
| Case | Encode time | Passes |
|---|---|---|
| 800×600 JPEG | 33 ms | 8 |
| 1920×1280 PNG | 84 ms | 8 |
| 1920×1280 JPEG | 123 ms | 8 |
| 1920×1280 WebP | 1266 ms | 8 |
Read the first three rows: the cost is per image, not per megabyte. Going from 800×600 to 1920×1280 is 5× the pixels and only 2.5× the encode time for JPEG. PNG is faster than JPEG per image here despite being a 2673 KB source, because the PNG branch searches over resolution rather than quality and can reuse the decoded bitmap.
The WebP row is the outlier, and the reason is worth knowing: browsers initialise the WebP encoder lazily, so the first WebP encode in a session pays a one-off warm-up cost. That is why it reads as 1266 ms against JPEG's 123 ms. In a batch of fifty, the warm-up is paid on the first file and the remaining forty-nine fall back to normal per-image cost.
What Actually Limits a Batch
Not the encoder. The things that bite are:
Decoded bitmap memory. A 1920×1280 image occupies about 9.8 MB as RGBA in memory while being processed. Fifty of those held simultaneously is half a gigabyte, which is how browser tabs die. Queueing one at a time keeps it at one image plus the queue's file handles.
Disk read speed. Reading fifty files from a rotating drive or a network share can take longer than encoding them. On a local SSD this is invisible; on a mapped network folder it is often the whole runtime.
PNG resolution loss. If your batch is PNGs and your target is aggressive, remember the PNG branch can only reach the target by shrinking the image — on the test image, a 200 KB ceiling meant 22.5% scale. Mixed batches where some files shrink and others do not can look inconsistent. Check one output before processing the whole set.
A Workable Batch Routine
- Pick the ceiling from the strictest consumer. If the images go to a portal that caps at 200 KB, use 200 KB — do not compress twice.
- Test on one file. Confirm the output looks acceptable at the resolution you will actually view it at, not at 400% zoom.
- Run the batch. Keep the tab in the foreground; background tabs get throttled by the browser and the queue slows down.
- Keep the originals. The suffix naming makes the compressed set obvious, but the compressed set is not a backup.
- Spot-check the smallest and largest output. Those are where a target-driven encoder is most likely to reveal a content mismatch.
Run it on your own file
This page explains the mechanism. The tool applies it — nothing is uploaded.
FAQ
Do I have to upload the images first?
No, and that is the point. The encoder runs on Canvas elements inside your browser tab, so the files are read from disk and written back to disk without ever crossing the network. There is no upload progress bar because there is no upload. You can go offline after the page loads and batches still work.
How many images can I compress at once?
There is no server-side cap, because no server is involved. The practical limit is your own memory: each image is held as a decoded bitmap while it is being processed, so a batch of very large 50-megapixel files on a phone will be slower and hungrier than the same batch on a laptop. For very large sets, run them in groups of twenty.
Can different images in one batch have different targets?
Set one target for the batch and every image is encoded to fit under it, each at its own highest quality that fits. If some images need a different ceiling — say form uploads at 200 KB and web thumbnails at 50 KB — run two passes. Each pass keeps its own targets and its own output names.
What happens to my file names and EXIF data?
File names are preserved with the target size appended, so photo-01.jpg becomes photo-01-100kb.jpg and you can tell processed files from originals at a glance. Note that re-encoding through a Canvas strips EXIF, which removes GPS coordinates along with camera metadata — useful for privacy, a problem if you need to keep capture data.
Is batch compression slower than doing them one by one?
It is the same total work, just queued. Each image still needs its eight binary-search passes; that is 33-123 ms per image in the measurements above. The gain is that you start the batch once and walk away instead of repeating the same three clicks fifty times, and the queue prevents the tab from trying to hold fifty decoded images at once.