Bulk Image Compressor
Compress multiple images (JPG, PNG, WebP) at once.
Drag & Drop Images
or click to browse files
About Bulk Image Compressor
Drop in a whole selection of JPEG, PNG and WebP files, choose one quality setting, and get every image back re-encoded at that setting in a single ZIP. The batch is worked through one file at a time, and each row updates with its own before and after size as it finishes, so you can watch which images are actually paying for themselves.
Resolution is deliberately preserved
This is the one behaviour that separates this tool from the single-file Image Compressor. That tool caps the longest side at 1920 pixels, which is the right default for something headed straight to a web page. This one changes nothing about the pixel grid — a 6000 x 4000 raw export comes back at 6000 x 4000, just lighter. That matters when the images are masters you will crop later, product photography that needs to survive a zoom control, or anything destined for print. If you want a batch resized as well, run it through the Bulk Image Resizer first and compress the output.
Working through a large batch
Files are queued and compressed sequentially rather than all at once. That is a deliberate trade: a parallel run would spike memory and could stall the tab on a laptop, while a serial run keeps the interface usable and the progress honest. You can keep adding files while a run is in progress, and you can delete a row you no longer want — neither will disturb the images already finished. Pressing the compress button again only picks up what is new or what the quality change invalidated.
A file the browser cannot decode is marked as an error on its own row and skipped; the rest of the batch carries on. Those rows are simply left out of the ZIP, so a single bad file never costs you the run. Inside the archive each entry is the original filename with a compressed- prefix, and duplicate names are given a numbered suffix instead of overwriting one another, which is easy to hit when several camera folders all contain an IMG_0001.jpg.
Everything runs on your own hardware. Decoding, encoding and zipping all happen inside this tab, using a Web Worker for the heavy encoding so the page does not freeze. No file, filename, or byte count is sent anywhere. The compression library does load its worker script on the first run — a single request for JavaScript, with none of your data in it — but that script is served from this site, so a batch run makes no cross-origin request whatsoever; and if it cannot be loaded the encoding falls back to the main thread, so the batch still completes offline. For a folder of client photographs or internal screenshots, that is a materially different privacy position from uploading it to someone else’s server.
Resolution is left alone
Every image keeps its original pixel dimensions. Only the encoder quality is lowered, which is what you want for product shots, print sources and anything that will be cropped later.
One shared quality setting
Pick a single quality target and it is applied to the whole batch, so a set of gallery images ends up visually consistent rather than each one tuned by hand.
Per-file before and after
Each row shows the original size next to the compressed size, so a file that barely shrank is obvious and you can drop it from the batch instead of shipping it.
ZIP with collision-safe names
Everything downloads as one archive. Two photos called IMG_0001.jpg from different folders become separate entries rather than one silently overwriting the other.
Nothing about the batch is uploaded
Every file is decoded and re-encoded by your own CPU in a Web Worker. No image, filename or size is ever sent anywhere, which matters when the batch is client work. Even the worker’s own script is served from this site, not a third-party CDN.
Frequently Asked Questions
How is this different from the single Image Compressor?
Two things. This tool takes a whole selection and returns a ZIP, and — more importantly — it keeps every image at its original pixel dimensions. The single-file compressor deliberately caps the longest side at 1920 px, which is right for the web but wrong if you are compressing masters, print sources or images that still have to be cropped.
How many images can I add?
There is no built-in cap. The real limit is your device memory, because every file is held in memory along with a preview and its compressed copy. A few hundred phone photos is comfortable on a laptop; on an older phone, work in batches of twenty or thirty.
Are the images processed in parallel?
No — they are compressed one after another, so the browser tab stays responsive and memory use stays flat instead of spiking. The encoding itself runs in a Web Worker off the main thread. Expect a large batch to take a while, and leave the tab open while it works.
I pressed Compress twice. Why did nothing happen the second time?
Files that are already done at the current quality setting are skipped, so pressing the button again is harmless and instant. Change the quality slider and press it again and the whole batch is redone at the new setting. Files you added mid-run are picked up on the next press.
One image failed. Did the batch stop?
No. A file that cannot be decoded is marked with an error on its own row and the run continues through the rest. You do not have to clear it before downloading: the ZIP is built only from rows that finished, so a failed file is simply left out of the archive.
Which formats can I mix in one batch?
JPEG, PNG and WebP, in any combination. Each file keeps its own format through the process, so a batch of mixed screenshots and photos comes back as the same mixture. HEIC photos from an iPhone cannot be decoded by the browser and should go through the HEIC to JPG converter first.
How does the quality slider affect PNGs in the batch?
Differently from JPEG. PNG has no quality parameter, so the encoder converts the slider into a colour count and quantises each PNG to that many colours — roughly 4,000 at 100% and around 400 at 10%. That makes PNG output here lossy. Screenshots, logos and flat graphics take it well and can shrink a lot; a photograph saved as PNG will start to band at low settings, and is better converted to JPEG or WebP with the Image Converter first.
Do the filenames change?
Each entry in the ZIP is your original filename with a compressed- prefix. If two files in the batch share a name, the second gets a numbered suffix so nothing is lost. Extensions are unchanged because the format is unchanged.
Is anything uploaded, even filenames?
No. The files are read locally, compressed locally and zipped locally by JSZip in the same tab. No image, filename or byte count is transmitted. The one request you will see in the Network tab is the compression library loading its Web Worker script on the first run — that is code, not your batch, and it comes from this site rather than the public CDN it used to. Go offline and it falls back to compressing on the main thread, so the whole job still completes.