Skip to content

Bulk Resize Images Online

Browser-side — no upload
Last verified May 2026 — runs in your browser

Bulk Image Resizer — Batch Lanczos Resampling via Canvas + 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 WHATWG File API + FileList interface (html.spec.whatwg.org/#filelist) over each selected file, decodes each via the browser's built-in JPG / PNG / WebP / AVIF decoder, and runs the same WHATWG Canvas 2D Context drawImage() resampling pipeline used by the single-image resize-image tool — imageSmoothingQuality = 'high' maps to a Lanczos-class kernel (Duchon 1979, Journal of Applied Meteorology 18(8):1016-1022) on Chrome / Edge / Safari / Firefox. Each result is serialised via HTMLCanvasElement.toBlob() back into the source format and exposed as a downloadable href via URL.createObjectURL — the original filename is kept so your naming scheme survives the batch. JPG, PNG and WebP inputs can be mixed in a single batch; the resampling step normalises everything to sRGB at 8-bit precision per IEC 61966-2-1:1999 (HDR sources are tone-mapped to SDR during drawImage). Because the entire pipeline is browser-side, the only bottleneck is your CPU and memory — not an upload connection. Files never leave the device.

Related: Resize Image Social Media Resizer Bulk Convert Compare Images Image Filters Compress Image

How to bulk resize images

  1. Drop multiple images onto the tool, or click to select a folder of files via the WHATWG File API multi-select input.
  2. 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.
  3. The browser iterates the FileList and runs drawImage() with imageSmoothingQuality = 'high' (Lanczos-class kernel) on each file, serialising the result via toBlob() in the source format.
  4. Wait for the batch. Modern desktops handle hundreds of photos per batch; mobile devices cap lower as memory pressure builds.
  5. 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 (ITU-T T.81 / ISO/IEC 10918-1), PNG (W3C 2nd Edition / ISO/IEC 15948:2004), and WebP (RFC 9649 Zern, Massimino, Alakuijala — November 2024) can all live in the same batch. The tool reads each source's MIME type and re-encodes via Canvas toBlob() into the same type, so the file extension you started with is the file extension you finish with.

Which resampling algorithm does each file use?

The same Canvas drawImage() with imageSmoothingQuality = 'high' that the single-image resize-image tool uses — Chrome / Edge / Safari / Firefox map 'high' to a Lanczos-class kernel (Duchon 1979) which is the industry-standard downscale filter (also what Pillow's Image.Resampling.LANCZOS uses; ANTIALIAS was an alias for LANCZOS until removed in Pillow 10.0.0, 1 July 2023). Every file in the batch gets the identical filter; the only 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 solves three problems that per-file workflows do not: (1) consistency. A design system or CMS image budget often requires every image at the same target width (e.g. 1200 px wide); doing 200 photos one at a time invites human error in the dimension field. The batch tool applies the identical drawImage(width, height) call to each file, guaranteeing the output width is exactly what you typed. (2) format preservation per file. Mixed-format batches (JPG product shots + PNG logos + WebP banners) round-trip through the canvas correctly because the tool reads each source's MIME type and re-encodes via toBlob() into the same type — JPG via Annex K quantisation tables (ITU-T T.81), PNG via DEFLATE (RFC 1951 Deutsch, May 1996), WebP via VP8 keyframe encoding (RFC 6386 + RFC 9649). The aspect-ratio-preserving math runs per file: target_height = round(source_height × target_width / source_width), so portraits and landscapes in the same batch each get their correct paired dimension. (3) privacy at scale. Uploading 200 high-resolution photos to a server batch-resizer means 200 round-trip transfers and 200 chances for the service to log, cache, or train on your data. The browser-local pipeline keeps everything in tabs memory; the only cost is CPU time and a few GB of heap during the batch. Practical limits depend on your device — modern desktops handle hundreds of photos per batch; phones cap lower as memory pressure builds. Output downloads either one-by-one or via a 'download all' bundle; 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 imageSmoothingQuality = 'high' (Lanczos-class kernel, Duchon 1979)
  • Aspect-ratio math per file: target_height = round(source_height × target_width / source_width)
  • Mixed-format batches: JPG (ITU-T T.81 Annex K), PNG (DEFLATE RFC 1951), WebP (VP8 RFC 6386 / RFC 9649) round-trip in source format
  • Original filenames preserved on download via URL.createObjectURL
  • Operates in sRGB (IEC 61966-2-1:1999) at 8-bit precision; HDR sources tone-mapped during resize
  • 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 (11)
  • 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.
  • Duchon, C. E. (1979). Lanczos Filtering in One and Two Dimensions. Journal of Applied Meteorology, 18(8):1016-1022 (August 1979) — Lanczos resampling reference for the per-image high-quality downscale path.
  • 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.

Sponsored

By ·