Compress images for a website: crop, resize, then encode
A practical image workflow for website covers and screenshots. Compare JPEG, PNG and WebP, choose dimensions, and inspect the final download.
One image, three separate decisions
Composition, display clarity and download size are separate decisions. Lowering quality aggressively cannot fix a subject that is too small or a crop that does not fit its destination.
For a square cover made from a landscape photo, decide where the subject belongs first. Cropping defines the frame, resizing defines the pixel dimensions, and encoding determines the final format and quality.
Why the order matters
Shrinking the entire photo before taking a small crop leaves fewer useful pixels in the final image. Crop the region you need first, then resize it to the intended dimensions.
Preserving aspect ratio prevents stretching, but does not make a landscape image fit a square cover. When the ratios differ, crop first instead of forcing unrelated width and height values.
Photographs and screenshots need different checks
Lossy encoding can reduce photograph size, but the actual output matters more than the quality setting. For screenshots, zoom in on small text and high-contrast edges: a thumbnail can hide blurred lettering.
If the image needs transparency, choose an output format that preserves it. JPEG does not retain an alpha channel, so a familiar extension is not a sufficient reason to choose it.
A smaller file still needs a final review
Re-encoding an already optimized image can make it larger. Compare actual byte counts; Neatbo displays input and output sizes so you can judge both size and appearance.
Before publishing, remove unnecessary metadata and reopen the downloaded file to inspect orientation, dimensions and transparency. Metadata removal is not complete anonymization: names or addresses inside the picture remain visible. Keep the original for future edits.
Worked example: a landscape photo becomes a square cover
Suppose the original is 2400 × 1600 and the destination needs a square. Crop a 1600 × 1600 region while positioning the subject, then decide whether the final file should be 800 × 800 or 1600 × 1600. The correct choice depends on display size and the pixel density you intend to support.
The 800 × 800 result has 640,000 pixels, while the 1600 × 1600 version has 2,560,000. This fourfold pixel difference is not a fourfold byte-size guarantee: texture, transparency and encoding all affect the file. Compare downloaded candidates instead of extrapolating a fixed compression rate.
For a screenshot containing text, the meaningful failure may be an unreadable label rather than an unattractive photograph. Review the output at the size at which users will see it. If lowering quality damages lettering before reaching your size target, reduce unused margins or revisit the layout rather than continuing to blur the text.
| Decision | Useful question | Evidence |
|---|---|---|
| Crop | What must remain in frame? | Subject position in the target aspect ratio |
| Resize | How many pixels will be displayed? | Layout dimensions and density requirements |
| Encode | Does the format preserve what matters? | Transparency and detail comparison |
| Publish | Did the delivered file stay correct? | Reopened download and actual bytes |
Before you finish
- Use a fresh export from the original for each comparison.
- Check dark and light backgrounds for transparent edges.
- Keep an original master for future crops.
- Use descriptive alternative text when publishing; it is a page-authoring task, not a compression setting.
References
- MDN: image file types
Background on image formats and transparency. Neatbo-specific behavior is described separately above.