Batch Image Processor

Fit inside a box constrains both axes and keeps the aspect ratio, so "max 512×512" means what everyone assumes it means: a wide image is limited by its width, a tall one by its height, and neither is stretched. By default images already smaller than the box are left alone — enlarging them would invent detail that is not there.

Scale by a factor multiplies every image by the same amount. Use it when the sources are already consistent — halving a folder of 2× assets, say — and avoid it on a mixed batch, where it just preserves the inconsistency at a new size.

Exact size forces every image to identical dimensions regardless of its aspect ratio, which distorts anything that does not already match. It is the right answer for icon sets and the wrong answer for almost everything else.

Two things go wrong with batch renaming, and both are silent.

The first is sort order. Without zero padding, asset_10 sorts before asset_2 in every file browser and most asset importers. The {i0} token pads to the width of the largest index in the batch, so a hundred files come out 001 to 100 and stay in order everywhere.

The second is collisions. Strip the extension off hero.png and hero.jpg, convert both to WebP, and you have two files called hero.webp. A ZIP archive will hold both entries quite happily — and the extractor will keep whichever it reads last, so your batch of 40 comes out as 39 with nothing to say why. Collisions are resolved with numbered suffixes before anything is written, comparing case-insensitively because Windows and macOS do.

Set sampling to nearest and scale by whole numbers. Anything else blurs the art or makes some pixels wider than others — the Pixel Art Resizer goes into why, and handles the single-image case with a preview.

Note that fit inside a box almost never produces a whole-number scale, because it derives the ratio from whatever the source happens to be. For a folder of pixel art, scale by a factor instead.