What Resizly does
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.”
Writing a rule
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}.webpWhat it applies to
Every 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.
What it does to the pixels
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 against a nine-point anchor. | A grid of tiles that all have to be the same shape. |
inside | Contain, and never larger than the source whatever else is set. | A mixed folder where some files are already small. |
cover here is arithmetic, not a decision: the box gives it a shape, the anchor gives it a corner, and nothing opens a handle to drag. If you need to choose where the cut falls, that is a different job on a different page.
Enlarging past the source is off in all three. 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.
What it is called
A template over seven 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.
Files it opens
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.
- Animated GIF and WebP are skipped with the reason logged, not flattened to a first frame nobody asked for.
- A CMYK JPEG is converted to sRGB, and the row that came from it is marked.
- Files with the same name in different sub-folders collide unless
{parent}is in the template. The plan flags the pair before the run, never during it. - Names carrying path separators or invisible direction characters are made safe for the archive, and the substitution is shown in the plan.
- Zero-byte and truncated files fail their own line and nothing else. The run carries on.
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.
Questions
Where do the files actually go?
Two rules want to write the same filename. What happens?
Why is 1920 missing from some of my outputs?
Can I stop half-way and keep what has already been written?
Do saved recipes follow me to another computer?
How many files before it stops being sensible?
What the formats cost
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.
Reference
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.