Format is part of the rule
Conversion and resizing are planned together because quality is spent when pixels are encoded, not when a filename changes. One decode feeds one resize and one WebP encode for each matching rule; the source is not repeatedly opened and compressed.
Quality 82 is a delivery starting point rather than a universal optimum. Raise it for fine text and shallow gradients; lower it for large photographic thumbnails whose dimensions already hide small differences.
| Picture | Look at | Likely adjustment |
|---|---|---|
| Portrait | hair against sky | raise quality if edges chatter |
| Screenshot | small type | keep dimensions, raise quality |
| Transparent graphic | soft alpha edge | compare against light and dark |
| Large photo | real bytes in ledger | lower quality if savings are weak |
Questions before the folder runs
Does WebP always make a smaller file?
No. It usually beats JPEG on photographic delivery copies and often beats PNG on screenshots, but a tiny, highly optimised source can already be smaller. The plan estimates size and the run ledger reports the real encoded bytes.
What happens to transparency?
WebP preserves an alpha channel. The rule does not flatten transparent pixels unless you explicitly choose JPEG, whose format has no alpha channel.
Can the original dimensions be kept?
Yes. Change the transform target or set a maximum larger than the source while leaving enlargement off. The rule then changes format without inventing a larger grid.
