Batch tool
Bulk Image Resizer
Drop a whole product set and resize every photo to the same dimensions in one pass. Three workers, one decode per file, one ZIP at the end.
- Per batch20 images · 20 MB each
- Parallelism3 Web Workers
- OutputZIP, one folder per target
Drop product photos here
Or . JPG, PNG, WebP, GIF, BMP or AVIF — up to 20 images, 20 MB each.
Nothing leaves your device. Files are decoded and re-encoded in this browser tab.
Output targets
Fills the frame and trims the overflow — the usual choice for product grids.
Settings apply to every image in the batch once you upload.
Export
Platform check
The custom output target applies no marketplace rules. Select Amazon, Etsy or Shopify to see their size, format and file-size checks.
How it works
Select 5 to 20 images
Multi-select in the file dialog or drag a group in. Non-images and oversized files are rejected with a named reason, never silently skipped.
Set one target size
1600 × 1600 by default. Aspect lock keeps the ratio honest, and crop-to-fill makes every output the exact same dimensions.
Prepare, review, download
Progress counts up per image. When it finishes you get thumbnails, measured file sizes, the folder tree, and a ZIP button.
How the batch actually runs
Each image becomes one job. A job is handed to an idle Web Worker, which decodes the file once and renders every selected output variant from that single bitmap. With three platforms selected, twenty photos cost twenty decodes rather than sixty.
The pool is capped at three workers — hardwareConcurrency - 1, clamped — because each in-flight job holds a full-resolution bitmap. Four workers on a 24 MP photo each is a fast route to a browser tab that dies mid-batch.
Failure is per image, not per batch
If one file cannot be decoded, the rest of the batch still completes. The failed image is listed with its error, the successful ones stay in the results, and Retry failed images re-runs only the failures. Nothing is overwritten and the originals are never modified.
Memory discipline
- Decoded bitmaps are closed as soon as their variants are rendered.
- Preview object URLs are revoked when you remove an image, clear the batch, or leave the page.
- Re-running the batch releases the previous output URLs first, so repeated runs do not leak.
- Canvas dimensions are validated before allocation — an absurd request fails with a message instead of a crash.
Questions
Why is the limit 20 images?
It is a memory budget, not a paywall. Twenty 20 MP photos decoded at once is roughly 1.6 GB of raw RGBA before any output is produced. The worker pool keeps the live set small, but the cap keeps the worst case survivable on a normal laptop.
Can I resize a folder without selecting files one by one?
Yes — drag the folder into the drop zone in Chrome or Edge and the browser expands it into a file list. Safari does not support folder drops.
Do all images get the same dimensions?
Yes. That is the point of a bulk resizer: one frame for the whole set. Crop-to-fill guarantees identical output dimensions even when the sources have different aspect ratios.
What if two source files have the same name?
The export planner detects the collision before processing starts and appends -2, -3 and so on. You can see the final filenames in the folder tree preview before downloading.
Does the tab stay responsive?
Yes. The decoding and encoding happen in workers; the main thread only receives finished Blobs. Rendering stays smooth while a 20-image batch runs.