Crop, then resize, then compress
Order matters and this is the first step. Cropping decides what the image is of; resizing decides how big it is; compression decides what it costs. Doing them in that order means each step works on the smallest correct input.
Doing it backwards — compressing then cropping — throws away detail you then crop out anyway, and re-encodes what is left a second time.
Ratios that matter
| Ratio | Where it is required | | --- | --- | | 1:1 | Avatars, product grids, app icons | | 16:9 | Video thumbnails, slide decks, most screens | | 4:3 | Print layouts, older displays | | 1.91:1 | Open Graph and Twitter card images | | 9:16 | Vertical video and stories |
Cropping to the ratio yourself beats letting a platform do it: their automatic crop is centred, and the subject of a photograph rarely is.
Work from the original
Every crop is destructive — the removed pixels are gone from the output. Keep the original and crop from it each time rather than cropping a crop, which compounds both the framing decisions and, for JPEG, the encoding loss.
Questions
Does cropping lose quality?+
The pixels you keep are untouched — cropping removes area, it does not resample. The one caveat is format: a JPEG has to be re-encoded to save, which adds a generation of loss. PNG and WebP lossless do not.
What do the ratio presets do?+
They lock the height to the width so the crop matches a target shape. Useful when the output has a fixed slot: 1:1 for avatars and product grids, 16:9 for video thumbnails, 1.91:1 for social cards.
Can I crop several images to the same box?+
Not in one pass — this works on one image at a time, because a fixed pixel box rarely suits several photographs with different subjects. For making a set the same size rather than the same crop, the [resizer](/t/image-resizer) is the tool.
What happens to transparency?+
It survives for PNG and WebP. A JPEG source has none to preserve, and if the format has to become JPEG the transparent area is filled with white.