Image Optimization: Compress, Resize and Convert
Images are usually the heaviest thing on a web page and the largest attachments in an email. They are also where the largest, easiest savings live: a photograph straight off a phone is routinely 4–6 MB, and the same picture at the size it will actually be displayed is often under 200 KB with no visible difference.
This guide covers the three operations that matter — resizing, compressing and converting — in the order that produces the smallest file for the least quality loss.
Resize first, compress second
This order is not a preference; it is the single biggest factor in the result.
Compression reduces the cost of storing each pixel. Resizing reduces how many pixels exist. If you compress a 6000-pixel-wide photo down to 300 KB and then resize it to 1200 pixels, you have thrown away detail twice and kept the artefacts from the first pass. Resize to the dimensions you will actually display, then compress once.
The practical rule: find the largest size the image is ever rendered at, double it for high-density screens, and resize to that. An image displayed in a 600-pixel-wide column needs to be 1200 pixels wide, not 6000. Use Image Resizer for this, then Image Compressor for the second step.
What compression actually discards
JPEG and WebP are lossy: they discard information the human eye is poor at noticing. Specifically, they divide the image into blocks, convert each to frequency components, and drop the high-frequency detail first — fine texture goes before broad shapes. They also store colour at lower resolution than brightness, because human vision is far more sensitive to luminance than to hue.
Two consequences follow, and they explain most bad results:
Photographs compress well; flat graphics do not. A photograph is full of the fine gradation this technique was designed for. A logo, screenshot or chart is full of hard edges and flat colour, which is exactly what produces visible ringing and smudging around text. Screenshots and line art belong in PNG or WebP lossless, not JPEG.
Quality 80 is the useful floor for photos. Between 100 and about 80 the file shrinks dramatically while the difference stays invisible at normal viewing size. Below roughly 70 the block structure starts to show in smooth areas — skies and skin are where it appears first. Compressing an already-compressed image compounds this, which is why a JPEG that has been saved four times looks soft.
Choosing a format
| Format | Use it for | Avoid it for |
|---|---|---|
| JPEG | Photographs, when maximum compatibility matters | Text, logos, anything needing transparency |
| PNG | Screenshots, line art, anything with transparency | Large photographs — files balloon |
| WebP | Almost everything; 25–35% smaller than JPEG at equal quality | Nothing practical; support is universal in current browsers |
| AVIF | Maximum compression, typically 50% below JPEG | Cases needing older software support; encoding is slower |
| SVG | Logos, icons, diagrams — infinitely scalable | Photographs, which it cannot represent |
WebP is the sensible default in 2026. It supports both lossy and lossless modes plus transparency, so it replaces JPEG and PNG in a single format, and every current browser reads it. Convert with Image Converter.
AVIF compresses harder still and is worth it for large hero images, but encoding takes noticeably longer and the gain over WebP is smaller than the gain WebP gave over JPEG.
Resizing without softening the result
Downscaling averages many source pixels into one, which slightly softens edges — this is inherent, not a flaw. A light sharpening pass afterwards restores the perceived crispness.
Never upscale to gain quality. Enlarging invents pixels by interpolating between the ones that exist; it can make an image fit a layout, but it cannot add detail that was never captured. If a client asks for a print-resolution version of a 600-pixel web image, the honest answer is that the original is needed.
Keep the aspect ratio unless you intend distortion. When an image must fill a specific box with a different ratio, crop it with Image Cropper rather than stretching it.
Metadata is size, and sometimes it is exposure
A photograph from a phone carries EXIF metadata: camera model, exposure settings, the date, and frequently the GPS coordinates of the place it was taken. This adds weight, and on a public image it can reveal a home address.
Some social platforms strip it on upload and some do not, so it is not safe to assume. Removing it deliberately with Remove EXIF is the reliable approach — and see what your photos reveal about you for what is actually in that data.
One caveat: EXIF also stores orientation. Strip it carelessly and a portrait photo may appear rotated, because the pixels were stored landscape with a flag saying "rotate this". A good tool applies the rotation before discarding the tag.
A workflow that holds up
- Start from the original, at full resolution. Never re-edit an already-compressed export.
- Crop to the composition you want.
- Resize to twice the largest displayed dimension.
- Convert to WebP, or AVIF for large hero images.
- Compress at quality 80 and inspect the smooth areas — sky, skin, gradients — at full size.
- Strip metadata before publishing anything public.
Every step above runs inside your browser on this site, so the originals — which are often the highest-resolution copies you own — never leave your device.
How small is small enough?
For web use, a full-width hero image should land under 200 KB and an in-article image under 100 KB. Thumbnails belong under 20 KB. These are guidelines rather than limits, but if a single image exceeds 500 KB it is almost always because it was never resized from the camera original.
For email, most providers cap attachments between 20 and 25 MB in total. A dozen unedited phone photos will exceed that; the same dozen resized to 2000 pixels will not come close.