Online Tool Store
Bulk Image Resizer
Resize up to 60 images at once with stepwise downscaling for clean results, convert format, and download them all as a ZIP. Nothing is uploaded.
🔒 This tool runs entirely in your browser. Your files are never uploaded to a server.
Applies to JPEG and WebP. PNG is lossless and ignores it.
| File | Original | Resized | Before | After | Change | Download |
|---|
Re-encoding drops metadata. EXIF, GPS coordinates and colour profiles do not survive, which is a privacy gain if you are posting photos and a loss if you rely on camera data or embedded copyright. Rotation is read from the file first, so portrait photos stay portrait. Converting an image with transparency to JPEG fills the transparent areas with white, since JPEG has no alpha channel.
How to use it
- Drop in up to 60 images. The table fills in with their real dimensions.
- Choose how to resize — fit in a box, fix one side, or scale by percentage.
- Pick an output format and quality, then press resize.
- Save individual files, or take the whole set as a ZIP.
Why the downscale happens in steps
The obvious implementation is one drawImage call at the target size,
and it is where most browser-based resizers lose quality. Reducing 4,000 pixels to 400 means every output pixel should
be the average of a 10 × 10 block of the original — 100 samples — and the browser's fast path does not take anything
like that many. What survives is a thinned selection of the original pixels, which is why fine lines shimmer and small
text turns to mush.
one step 4000 → 400 each output pixel from a 10×10 area, undersampled
halving 4000 → 2000 → 1000 → 500 → 400
each step averages a 2×2 block, which is exactly what it should
So anything shrinking by more than half is halved repeatedly until one final step lands on the target. It costs a few extra canvas draws and it is the difference between a usable thumbnail and a smeared one.
The ZIP is written by hand
Bundling the results needs a ZIP, and the usual answer is to pull in a library. This one writes the archive directly, because the stored — uncompressed — form of the format is small enough to implement correctly:
per file local header 30 bytes + filename, then the bytes
per file central directory 46 bytes + filename
once end record 22 bytes
each entry needs a CRC-32 of its contents
Storing rather than deflating is not a shortcut. JPEG, PNG and WebP are already compressed, and deflate has nothing left to find: run it over high-entropy data and the output is slightly larger — 200,065 bytes from 200,000, an overhead of 0.03%. Storing keeps the packing instantaneous and the archive the same size it would otherwise be.
A hand-written binary format is exactly the kind of thing that is subtly wrong until something refuses to open it, so
this one was checked rather than assumed: the CRC-32 implementation reproduces the known value 414fa339 for the
standard pangram, and archives built by this same code pass unzip -t
with no errors, including nested paths and non-ASCII filenames.
What re-encoding costs you
Every image here is decoded to pixels and written back out, which has consequences worth knowing. All metadata goes: EXIF, GPS coordinates, camera model, embedded colour profiles and copyright fields. For posting photos publicly that is a feature — location data is the single most common accidental disclosure in shared images — but if you depend on that data, resize a copy.
Orientation is handled separately and deliberately. Phone cameras often store a landscape image with a rotation flag rather than rotating the pixels, and a naive decode ignores the flag and produces a sideways photo. The decode here asks for the file's own orientation to be applied first.
Finally, re-encoding a JPEG is generation loss: it is lossy compression applied to already lossy output. At quality 82 it is hard to see, but resizing the same file repeatedly will degrade it. Keep the originals.
FAQ
Are my images uploaded anywhere?
No. Every image is decoded, resized and re-encoded in the page, and the ZIP is assembled in the browser too. Nothing is sent to a server, which is the main reason to use this rather than a site that asks you to upload a folder of photos.
Why do my resized images look sharper here than elsewhere?
Because a large reduction is done in halving steps rather than in one go. Asking a browser to draw a 4,000-pixel image straight into 400 pixels means each output pixel is built from a 10×10 area that it does not fully sample, so thin lines and small text break up. Halving repeatedly averages a 2×2 block each time, which is what a proper filter would do.
Does it keep EXIF data and GPS coordinates?
No — re-encoding through a canvas drops all metadata. That is a privacy gain if you are posting photos, since location and camera details go with it, and a loss if you rely on embedded copyright or colour profiles. Rotation is the exception: it is read from the file before drawing, so portrait photos stay portrait.
Why is the ZIP not compressed?
Because there is nothing left to squeeze. JPEG, PNG and WebP are already compressed, and running deflate over them gains essentially nothing — on high-entropy data deflate actually adds about 0.03% in overhead. Storing the files uncompressed inside the archive keeps the packing instant and the result the same size.
What happens to transparency if I convert to JPEG?
It is filled with white before encoding. JPEG has no alpha channel at all, so transparent areas have to become something — and left alone they come out black. The tool paints a white background first, which is almost always what people expect.
Why will it not enlarge my images by default?
Because scaling up adds pixels without adding detail — the result is bigger and blurrier, not better. There is a switch for it, since sometimes you genuinely need an exact size, but it is off unless you ask.
How we compare
| Feature | Online Tool Store | Upload-based resizers | ImageMagick or Photoshop |
|---|---|---|---|
| Images never leave your device | ✓ | ✗ | ✓ |
| Stepwise downscaling for clean thumbnails | ✓ | Varies | ✓ |
| No upload wait, no queue, no file-count limit charge | ✓ | ✗ | ✓ |
| ZIP of the whole set, no dependency | ✓ | ✓ | Separate step |
| Strips GPS and EXIF automatically | ✓ | Usually | Only if asked |
| Preserves metadata and colour profiles | ✗ | ✗ | ✓ |
| Scriptable over thousands of files | ✗ | ✗ | ✓ |
For a folder of photos that needs to be smaller before it goes anywhere, this is the quickest route that does not involve handing them to someone else's server. For thousands of files, or for work where the metadata and colour profile have to survive, a command-line tool is the right instrument.