Bulk Image Resizer — Batch Canvas Resizing + File API
Drop a whole folder of photos and resize them to a target width in one pass, with aspect ratio preserved per file. The tool iterates the browser File API over each selected file, decodes each image locally, draws it to a new Canvas at the calculated dimensions and creates a downloadable copy with toBlob(). JPG, PNG and WebP inputs can be mixed in a single batch; the current tool outputs PNG for PNG inputs and JPG for other supported inputs. Because the entire pipeline is browser-side, the main limits are your CPU and memory — not an upload connection. Files never leave the device.
How to bulk resize images
- Drop multiple images onto the tool, or click to select a folder of files via the WHATWG File API multi-select input.
- Enter the target width in pixels. Heights are calculated per file as round(source_height × target_width / source_width) so each image keeps its native aspect ratio.
- The browser iterates the FileList, draws each image to a new canvas and creates a copy via toBlob().
- Wait for the batch. Modern desktops handle hundreds of photos per batch; mobile devices cap lower as memory pressure builds.
- Download files one by one, or grab the full batch at once. Original files on disk are never modified.
Common use cases
- Resizing a batch of product photos for an online store so all thumbnails share an exact pixel width (e.g. 600 px) for the CMS image grid.
- Preparing a folder of blog images at 1200 px wide before uploading to a CMS that has a per-image weight budget.
- Down-scaling camera shots for a photography portfolio that serves responsive 1× / 2× / 3× srcset variants.
- Normalising image libraries after mixing exports from different cameras and phone models (assorted source dimensions reduced to a single target width).
- Generating consistent-width thumbnails for an e-commerce catalogue without per-file manual work in a desktop editor.
Frequently asked questions
Is there a limit on how many images I can resize?
No hard limit — performance depends on your browser, device memory, and source file sizes. Modern desktops handle hundreds of photos per batch; phones cap lower as the browser's heap fills up with decoded ImageBitmaps. Because everything runs locally, there is no server timeout — the batch will complete eventually as long as memory allows.
Does the tool keep the aspect ratio?
Yes. You set the target width and the tool computes target_height = round(source_height × target_width / source_width) for each file individually, so portraits and landscapes in the same batch each get their correct paired dimension. None of them get stretched or squashed.
Can I mix formats in one batch?
Yes. JPG, PNG and WebP can live in the same batch. PNG inputs produce PNG output; other supported inputs produce a JPG copy.
Which resampling algorithm does each file use?
The batch tool uses the browser's Canvas drawImage() pipeline. The exact smoothing implementation is browser-defined and is not advertised here as Lanczos. Every file follows the same pipeline; the per-file variation is the source-to-target dimension ratio.
Are my images uploaded?
No. The browser handles everything through the WHATWG File API and Canvas 2D Context. No file leaves your device — DevTools Network tab shows zero upload requests during the batch. The downloaded results are exposed as URL.createObjectURL hrefs from the in-memory Blobs, not from a server.
What batch resize gets you over per-file resize — and the local-only constraint
Batch resizing helps with consistency and avoids repetitive manual work: the same target width and aspect-ratio calculation is applied to every selected file. Mixed-format batches can be processed together; the current output follows the tool behaviour, producing PNG for PNG inputs and JPG for other supported inputs. Practical limits depend on device CPU and memory, especially for large folders. Output downloads either one by one or through the 'download all' bundle, and the original files on disk are never modified.
- Batch loop iterates WHATWG File API FileList (html.spec.whatwg.org/#filelist) — drag-and-drop or input multiple
- Per-file Canvas drawImage with browser-defined smoothing
- Aspect-ratio math per file: target_height = round(source_height × target_width / source_width)
- Mixed-format batches with current JPG/PNG output behaviour
- Original filenames preserved on download via URL.createObjectURL
- Practical limit hundreds of photos per batch on desktop, lower on mobile (CPU + memory bound, not upload bound)
- Browser-side via WHATWG Canvas + File API — files never leave the device
Free. No signup. No file uploads. Ads via AdSense (consent required).
Sources (10)
- WHATWG (live). HTML Living Standard — Canvas 2D Context: drawImage() + imageSmoothingQuality. html.spec.whatwg.org/#dom-context-2d-drawimage — same Canvas resampling pipeline applied per file in the batch; imageSmoothingQuality 'high' for downscaling, 'low' for nearest-neighbour-style fast resize.
- WHATWG (live). HTML Living Standard — File API + FileList + drag-and-drop interfaces. html.spec.whatwg.org/#filelist + w3.org/TR/FileAPI/ — browser-side multi-file selection (input type=file multiple, drag-and-drop DataTransfer.files) iterated client-side without upload.
- WHATWG (live). HTML Living Standard — HTMLCanvasElement.toBlob() + URL.createObjectURL. html.spec.whatwg.org/#dom-canvas-toblob + url.spec.whatwg.org/#dom-url-createobjecturl — per-file output Blob serialised in the browser; createObjectURL exposes the resized result as a downloadable href without server round-trip.
- Python Imaging Library (PIL Fork) — Pillow contributors (2023). Pillow 10.0.0 — Image.Resampling enum. pillow.readthedocs.io/en/stable/releasenotes/10.0.0.html — industry reference for batch image processing resampling filters (NEAREST / BILINEAR / BICUBIC / LANCZOS).
- ITU-T (CCITT) Study Group VIII & ISO/IEC JTC 1/SC 29/WG 10 (JPEG) (1992). Information technology — Digital compression and coding of continuous-tone still images: Requirements and guidelines. ITU-T Recommendation T.81 (18 September 1992) / ISO/IEC 10918-1:1994 — JPG re-encoding via Annex K quantisation tables for each resized JPG file in the batch.
- W3C (PNG Working Group) (2003). Portable Network Graphics (PNG) Specification (Second Edition). W3C Recommendation 10 November 2003 / ISO/IEC 15948:2004 — PNG re-encoding for each resized PNG file in the batch; lossless DEFLATE compression preserves the resampled pixels exactly.
- Deutsch, P. (1996). DEFLATE Compressed Data Format Specification version 1.3. RFC 1951, IETF (May 1996, Aladdin Enterprises — LZ77 + Huffman; 32 KB sliding window) — PNG IDAT compression algorithm applied per file in the batch.
- Zern, J., Massimino, P., & Alakuijala, J. (Google LLC) (2024). WebP Image Format. RFC 9649, IETF (November 2024, Informational) — WebP re-encoding for each resized WebP file in the batch; lossy mode (VP8 keyframes) and lossless mode (LZ77 + Huffman/prefix coding) both round-trip cleanly through Canvas toBlob('image/webp', quality).
- Bankoski, J., Koleszar, J., Quillio, L., Salonen, J., Wilkins, P., & Xu, Y. (Google Inc.) (2011). VP8 Data Format and Decoding Guide. RFC 6386, IETF (November 2011, Informational) — VP8 keyframe bitstream used by WebP lossy mode in the batch re-encoding pipeline.
- International Electrotechnical Commission (IEC) (1999). Multimedia systems and equipment — Colour measurement and management — Part 2-1: Default RGB colour space — sRGB. IEC 61966-2-1:1999 — default Canvas 2D colour space; mixed-format batches (JPG + PNG + WebP) are normalised to sRGB during the canvas resampling step.
These are the W3C, ISO/IEC, ITU-T, and IETF specifications the tool implements or builds on. Locate them on w3.org, iso.org, itu.int, or datatracker.ietf.org.