How many photographs can go in one job?

Five thousand files or twenty gigabytes, whichever the folder reaches first. The ceiling is shown before the traversal rather than discovered halfway through it, and a folder past the limit is cut at the ceiling with the rest left untouched.

What happens to the originals?

Nothing. Every file is opened for reading, and the results are written into a separate archive. No source file is modified, renamed or deleted at any point, by this site or by anything it runs.

Why are my camera files so much larger than my phone's?

Usually because they are large because they are 6000 pixels wide, not because they are badly compressed. A quality setting writes the same number of pixels more cheaply; capping the long edge writes fewer of them, which is the bigger lever. A rule with several outputs per source — one set for a page, one for an archive — is a different job, and resizly.com is built for it.

The record of what finished is written after every file, so the answer is yes and the cost depends on the browser. Chrome and Edge hand the folder back on return. Safari and Firefox keep the record but need the folder chosen again, at which point finished files are matched and skipped.

Why is one file at a time the default?

Because four 48-megapixel photographs decoding simultaneously is the most reliable way to have a browser tab killed, and a job that dies at file nine hundred has wasted more time than a slow one ever will. The setting goes up to four for machines with the memory for it.

Compress multiple photos at once

What this does

A folder of photographs is a storage problem wearing the costume of an image problem. The individual pictures are usually fine. There are simply four thousand of them, each written by a camera that had no reason to be economical, and together they are the reason a laptop is full.

So this is a queue rather than an editor. You choose a folder, you declare one rule, and every file in the folder meets that rule in turn. Each one gets a row: what it weighed going in, what it weighs coming out, and — where nothing was written — the reason in words. At the end there is a single line of arithmetic and an archive shaped like the folder you started with.

The rule is deliberately short. Three quality positions with their encoder numbers printed beside them, an optional cap on the long edge, a choice about capture information, and two skip rules. Nothing about this rule is clever, and that is the point: a clever rule applied four thousand times is four thousand decisions nobody audited.

Setting the rule

Quality is the setting most people mean by compression. It rewrites the same pixels more cheaply, and the three positions here are printed with the numbers the encoder actually receives.
The long edge cap is the largest saving available on camera files and the only part of the rule that cannot be undone from the output, so it is off until you turn it on.
Capture information — the date, the camera, sometimes the place — is kept by default. What removing it would have saved is reported separately, so that choice can be made on a number rather than on a feeling.
The two skip rules keep the total honest. Files under the floor are never opened, and a re-encode that came out larger is thrown away with the original kept in its place.

What it will open

JPEG, PNG and WebP are read and written. HEIC is not: this build has no decoder for it, so the pickers do not offer the format and the pre-run summary counts what is in the folder and says it is being left alone. Every file is still identified from its leading bytes rather than its extension, so a HEIC renamed to .jpg is recognised as HEIC and reported as such rather than failing in a decoder that was never going to read it.

Anything else in the folder is counted and left alone: video, audio, sidecar files, RAW from any camera, and the half of a Live Photo that is a movie. Those are reported as unsupported rather than as failures, which is a distinction that matters in a report somebody is meant to trust before they delete anything.

Two kinds of file are skipped on purpose even though they could be opened. A CMYK JPEG would come back with its colours shifted, and a colour shift applied silently across a thousand files is worse than a skip. A photograph beyond what this browser can decode is skipped with its dimensions on the row instead of taking the job down with it.

Questions about long jobs

How many photographs can go in one job?: Five thousand files or twenty gigabytes, whichever the folder reaches first. The ceiling is shown before the traversal rather than discovered halfway through it, and a folder past the limit is cut at the ceiling with the rest left untouched.
What happens to the originals?: Nothing. Every file is opened for reading, and the results are written into a separate archive. No source file is modified, renamed or deleted at any point, by this site or by anything it runs.
Why are my camera files so much larger than my phone's?: Usually because they are large because they are 6000 pixels wide, not because they are badly compressed. A quality setting writes the same number of pixels more cheaply; capping the long edge writes fewer of them, which is the bigger lever. A rule with several outputs per source — one set for a page, one for an archive — is a different job, and resizly.com is built for it.
Can I close the tab?: The record of what finished is written after every file, so the answer is yes and the cost depends on the browser. Chrome and Edge hand the folder back on return. Safari and Firefox keep the record but need the folder chosen again, at which point finished files are matched and skipped.
Why is one file at a time the default?: Because four 48-megapixel photographs decoding simultaneously is the most reliable way to have a browser tab killed, and a job that dies at file nine hundred has wasted more time than a slow one ever will. The setting goes up to four for machines with the memory for it.