Rules a folder can share
A folder holds landscape photographs, phone portraits and square graphics together. A rule has to mean something for each of them, so the queue offers proportions and edges rather than one pixel pair, and prints what each rule does before anything runs:
| Rule | 6000 × 4000 | 3024 × 4032 | 1200 × 1200 |
|---|---|---|---|
| 50 % | 3000 × 2000 | 1512 × 2016 | 600 × 600 |
| Long edge 1600 | 1600 × 1067 | 1200 × 1600 | 1200 × 1200 |
| Short edge 1080 | 1620 × 1080 | 1080 × 1440 | 1080 × 1080 |
| Inside 1920 × 1080 | 1620 × 1080 | 810 × 1080 | 1080 × 1080 |
The kernel follows the same rule as the single-picture lab — Lanczos going down, bicubic going up — decided per picture, and each row names the one it took. A resolution tag can be written into every JPEG and PNG in the same pass.
What a queue does not do
- It does not crop. Fill-and-crop needs a decision per picture about where the cut falls; use the pixel-size page for those one at a time.
- Resolution only works on JPEG and PNG, the two containers with a standard field. WebP, GIF, BMP and the rest are reported as failed rather than silently re-encoded.
- A size limit on PNG can only move the pixel count; PNG has no quality to lower. Write JPEG when the limit matters more than lossless pixels.
Questions
Can one pixel size be applied to a whole folder?
Not without distorting most of it, because the pictures are different shapes. The queue asks for a rule each picture can meet in its own proportions: a percentage, a longest side, a shortest side, or a box every picture is fitted inside. Each row then reports the exact size it came out at.
What does “Resolution only” do to the files?
Nothing to the pixels. Each JPEG and PNG has its resolution field rewritten in the original bytes — JFIF and Exif in a JPEG, pHYs in a PNG — and every other byte is copied through. No decode, no canvas, no re-encode, so there is no quality loss at all. Formats without a standard field are listed as failed with that reason.
Can every file be kept under a size in KB?
Yes. Turn on the size limit and each file is searched separately: JPEG or WebP quality first, never below 0.40, then — only if you allow it — the pixel count in 5 % steps through the same kernel. Each row says what moved, and the CSV records it.
What is in the CSV receipt?
One row per file: the name you opened, the name written, its state, input and output pixel dimensions, the resolution written and which containers carry it, whether the pixels were re-encoded or copied, the kernel, the byte length, the KB decision and the SHA-256 of the written file. It is built in the tab and saved like any other download.
How many pictures can one queue take?
Five hundred on a desktop and one hundred on a phone. Beyond that the queue lists the first batch and says how many are left, because each file in flight holds a full decoded copy in memory and a browser tab that runs out is killed without warning.
Are the files uploaded anywhere?
No. Each picture is decoded, resampled and encoded in this tab, and the ZIP is assembled in memory here. The page has no endpoint that could receive an image.
Neighbouring measurements
One picture with an exact box? The pixel-size page shows the crop. Only the print size wrong? Change the DPI and leave every pixel alone.
- Change image size in pixelsA box in pixels: fit inside, fill and crop, or stretch, with the factor printed.
- Resize an image to a KB limitQuality first, pixels only if allowed, and a sentence saying which moved.
- Change DPIRewrite the density tag without touching a pixel.
- Downsize an imageSmaller without moiré: an area-average pass before the kernel.
