Drop the whole folder, write the rules once, and get a ZIP with every file at every size you needed. Two hundred at a time, on your own machine.
Drop a folder. Or 200 files.
One picture opens the size matrix: every platform size, cropped where you point.Sub-folders are kept, so a folder name can go in a filename.
/a paste works too/
Every file, named and measured, before anything runs.
Drop a folder and this fills in: one row per file that will be written, with its name, its size and an estimate of its bytes, plus every collision and every dropped width. Nothing runs until it is on screen.
Nothing to run yet.
That is the ledger, mid-run. One line per file as it is written, newest at the bottom, and the real byte count rather than the estimate.
Nothing runs until the plan has been shown, so here is one, worked out by the same function the tool uses — on a folder described rather than uploaded. Every row below, including the suffix and the note, came back from that function rather than being written here.
*.jpg → max-w 1600 / contain / webp q82 / {name}-{w}.{ext}
Only the JPEGs, held inside 1600 across, written as WebP. Nothing is enlarged, so a source already smaller than the box is written at its own size. The format choice is per rule, not per run.
* → box 400x400 / cover centre / webp q82 / {name}-{w}.{ext}
Every file, cropped to a 400 square from the centre. The box gives the crop its shape and the focal point its position — the centre until you drag it in the matrix — and the plan prints the source rectangle it will draw from.
* → box 400x400 / cover centre / webp q82 / 2x / {name}-{w}.{ext}
The same tile at twice the pixels, and it lands on its own filename without being told to: {w} resolves to the width the rule actually writes, so the 2x tile is -800 rather than a second -400. Name it by intent instead and the naming reference has the token for it.
| Source | Rule | Writes | Pixels |
|---|---|---|---|
| DSC_0041.jpg | Listing | DSC_0041-1600.webp | 1600×1067 |
| DSC_0041.jpg | Grid tile | DSC_0041-400.webp | 400×400 |
| DSC_0041.jpg | Grid tile, 2x | DSC_0041-800.webp | 800×800 |
| DSC_0102.jpg | Listing | DSC_0102-1200.webpsource is only 1200x800; written at its own size | 1200×800 |
| DSC_0102.jpg | Grid tile | DSC_0102-400.webp | 400×400 |
| DSC_0102.jpg | Grid tile, 2x | DSC_0102-800.webp | 800×800 |
| logo.png | Grid tile | logo-400.webp | 400×400 |
| logo.png | Grid tile, 2x | logo-800.webp | 800×800 |
A responsive set is the same idea with the widths filled in for you, and it drops any width larger than the source rather than inventing pixels — the srcset page opens with one already built, and prints the markup beside the plan.
It takes a folder rather than a file. You write the rules once, look at the list of files those rules are going to produce, and then let it run. What comes back is a ZIP, built while the run is going rather than assembled at the end, so a job that writes two gigabytes does not need two gigabytes of memory to finish.
The order on the page is the order of the job: what is queued, what the rules are, what will be written, and the run. Nothing is decoded while you are writing rules — only the first sixty-four kilobytes of each file are read, which is enough for its format, its size, its orientation and whether it is animated. That is why the count and the plan appear immediately on a folder that would take a minute to open.
A source is processed by every rule it matches, in order. That is how one photograph becomes a listing image, a grid thumbnail and a zoom view in one pass, decoded once rather than three times.
What this tool is not going to beat
“A shell script with ImageMagick on the same machine will finish faster than this page, and it always will. What you get here instead is not installing anything, seeing the file list before it is written, and being able to hand the recipe to someone who has never opened a terminal.”
A rule is four things, and the card header prints all four as one line so a stack of six can be read without opening any of them:
max-w 1600 / cover centre / webp q82 / {name}-{w}.webpEvery file, or a filename pattern. * matches within one folder, ** matches across them, so **/product/*.jpg finds the JPEGs in every product folder in the drop and hero-* finds anything starting with hero- wherever it sits.
A target — a maximum width, a maximum height, a maximum long edge, or an explicit box — and then one of three behaviours:
| Fit | What comes out | When to use it |
|---|---|---|
contain | Fits inside the box, keeps the ratio, may be smaller than the box in one direction. | Anything where the whole picture has to survive. |
cover | Fills the box exactly and cuts the overflow away around a focal point (the matrix calls it Fill). | A grid of tiles, or a story and a banner cut from one photo. |
pad | The whole picture, centred on a canvas exactly the box's size, padded in white, black or transparency. | A logo or a product that must not lose an edge to a crop. |
inside | Contain, and never larger than the source whatever else is set. | A mixed folder where some files are already small. |
Where a cover cut falls is yours to decide, per target. Drag the focal point on the original or drag inside any tile of the size matrix, type the percentages, or ask for a suggestion; the rule stores the point as a fraction of the picture, so the same rule lands on the same subject across a whole folder.
Enlarging past the source is off in every fit. Turn it on and a 900-wide photo in a 1600 rule is written at 1600, softer than it was. Leave it off and the same photo is written at 900, and the plan says so.
A template over nine tokens, defaulting to {name}-{w}.{ext}. A literal slash makes a folder inside the archive. The tokens, the collision policy and a set of worked filenames are on the naming reference.
One control expands into several rules: a responsive set takes a width list, the pixel ratios you want and one format, and prints the srcset markup beside the plan. That job has its own page.
Every source is handed to the browser’s own decoder, so what opens depends on the browser you are in. JPEG, PNG, WebP and GIF open everywhere; AVIF opens in anything current; BMP, TIFF and ICO are opened by some browsers and turned away by others, and a refusal costs that one line and nothing else. HEIC, which is what a recent iPhone shoots unless it has been told otherwise, is the exception no browser handles: the first one in a run pulls down a WebAssembly codec of about a megabyte and a half, and every HEIC behind it reuses the copy already in memory. It writes JPEG, PNG and WebP.
{parent} is in the template. The plan flags the pair before the run, never during it.Two hundred files on a phone is a bad idea
iOS is the real ceiling. Safari holds far less in memory than a laptop, its canvas limits are lower, and when it runs out it drops the tab rather than telling you. A run that would take three minutes on a laptop can die at file 140 on an iPhone with nothing written. Use a phone for a few dozen files and a computer for the folder.
Format is a per-rule field rather than a global setting, because the four outputs of one photograph rarely want the same one. What each costs, on a typical 800-pixel photograph:
| Written as | Roughly | Keeps alpha | Use it when |
|---|---|---|---|
| WebP q80 | 40-60 KB | yes | Anything going on a web page. It is the default for a reason. |
| JPEG q82 | 70-100 KB | no | Something downstream that predates WebP and will not be argued with. |
| PNG | 300-600 KB | yes | Flat colour, lettering, or an alpha channel that has to survive exactly. |
| Keep source | unchanged | as the source | A pass where only the size is meant to change. |
PNG has no quality control, so the field is ignored rather than quietly doing something. Keep-source on a format no browser can write — a TIFF, a BMP, an AVIF — becomes PNG and the plan row says so, because spending quality on a file whose format you never asked to change is not a decision this tool makes on its own.
Three things it will not do with a format, and the reason in each case. It does not write AVIF: browsers encode it slowly enough that a folder of two hundred would be a different kind of wait, and the engine here is built around finishing. It does not search for a file size — you set an encoder quality and get whatever that produces, because hitting a byte count means encoding the same picture five times. And it does not flatten an animation to its first frame; an animated GIF or WebP is skipped with its reason in the plan, since a silently still animation is worse than a file that was not written.
Six pages below, three of them guides longer than this one. The reference material answers what a field does; the guides answer what to put in it, which is the slower question. About, Privacy and Terms are in the footer.