Resize multiple images at once, free

Max dimension versus exact size

Max-dimension mode caps the longest side of each image at a value you choose and scales the rest proportionally, so every image keeps its own aspect ratio. A landscape and a portrait both come out with their longest edge at, say, 1920 pixels, but they keep their shapes.

This is the right mode for a mixed folder of photos. Cameras and phones produce a variety of orientations and ratios, and max-dimension mode respects all of them while guaranteeing that nothing exceeds your limit. It is the safe default for general resizing.

Exact-size mode forces every image to the same width and height, full stop. This is what you want when uniformity is the goal, for example a grid of product thumbnails that all must be 800 by 800, or a set of avatars that must match precisely.

The catch with exact mode is shape. If your images do not already share the target aspect ratio, forcing them to identical dimensions stretches or squashes them. So reach for exact mode when the batch is already consistent in shape, and max-dimension mode when it is not.

Resizing is the biggest file-size win there is

File size scales with pixel count, and pixel count scales with the square of the dimensions. Halving an image's width and height does not halve its size, it roughly quarters it, because you are removing three quarters of the pixels.

That is why resizing usually beats compression for shrinking a heavy file. Dropping a 4000-pixel photo to 1200 pixels removes the vast majority of its data before you even touch the quality setting, which is data the viewer was never going to see at display size anyway.

The two techniques stack. Resize first to remove the pixels you do not need, then compress the smaller image to trim what remains. A 9 MB photo resized to web dimensions and then compressed can land under 200 KB, a saving no amount of compression alone would reach.

For a whole batch the effect is dramatic. A folder of full-resolution photos resized to a sensible web width can lose ninety percent of its total weight, turning a load that crawls into one that snaps, with no visible difference at the size people actually view.

Choosing a target size for the web

For full-width content images and blog headers, a longest side around 1600 to 1920 pixels is the common target. It looks crisp on large and high-resolution screens without carrying pixels that a normal layout will never show.

For in-article images and product photos, 1000 to 1200 pixels is usually plenty. These sit in a column rather than spanning the page, so they need fewer pixels, and capping them there keeps a gallery light without any visible softening.

For thumbnails, avatars, and grid tiles, 400 to 800 pixels covers most designs, including the extra density that high-resolution screens want. Below that, text and fine detail start to suffer, so it is the practical floor for anything people look at closely.

When in doubt, max-dimension mode at 1920 is a safe one-size-fits-all rule for a mixed batch headed to the web. It guarantees nothing is oversized while leaving each image sharp, and you can always run a tighter pass for thumbnails afterward.

What enlarging can and cannot do

Resizing down is essentially free in quality terms. You are discarding pixels you do not need, and the result looks identical at the smaller size, so there is no reason to hesitate about shrinking a batch to fit its purpose.

Resizing up is a different matter. Enlarging an image cannot create detail that the camera never captured; it can only spread the existing pixels over a larger area and interpolate between them, which makes the result larger but softer and slightly mushy.

For a batch this means enlarging is a last resort, used only when you have no higher-resolution source and the layout demands more pixels. Accept that the enlarged images will look softer than native ones, and avoid extreme jumps, which exaggerate the softness.

The practical rule is simple: resize down freely across a whole folder, and resize up only when you must, knowing it is a compromise rather than a clean gain. Where possible, go back to the original high-resolution files instead of enlarging small copies.

How bulk resizing works on your device

When you drop a folder, each image is decoded and redrawn onto an HTML canvas at the dimensions your rule specifies, using high-quality smoothing so downscaled images stay sharp. The resized canvas is then encoded back to the file's original format.

It all runs locally. Your browser does the work across its CPU cores, handling several images at once, and bundles the results into a ZIP. The originals never leave your device, so there is no upload, no server queue, and no waiting on a remote round-trip.

That local design keeps the batch private. Because no file is sent anywhere, none of your images sit on someone else's server, get logged, or risk being cached online, which matters for private photos, client work, and anything sensitive.

And it keeps the tool free with no catch. There is no account, no watermark, and no per-file fee, because the resizing uses your machine rather than rented servers. The only real limit is your device's memory, so you can run batch after batch. If you also need each file smaller in bytes, pass the resized set through the bulk compressor afterward.