How to optimise images for the web
A 4 MB photo on your home page costs seconds of loading time. Here is how to bring it down to 150 KB with no visible loss.
A photo straight out of a DSLR or a recent smartphone weighs between 3 and 8 MB and is often 4,000 pixels wide. Drop it into an 800-pixel block on a home page and the browser will scale it down on screen — but download every last byte of it. On an ordinary mobile connection that means several seconds during which the visitor stares at an empty rectangle. Optimising an image for the web means getting that file under 200 KB without anyone noticing the difference on screen.
Resize first, compress second
The order matters, and most people get it the wrong way round. An image of 4,000 × 3,000 pixels holds 12 million pixels; the same image at 1,600 × 1,200 holds 1.9 million, roughly six times less data to encode. No compression setting closes that gap: a file 4,000 pixels wide squeezed to quality 50 is still heavy and visibly grubby, while the same image reduced to 1,600 pixels and then compressed at quality 82 comes out lighter and cleaner.
To pick your target width, measure the real width of the block the image sits in, then double it to cover high-density screens:
- List thumbnail or avatar: a block of 300 to 400 px, so export at 600 to 800 px.
- Article illustration: a block of 700 to 800 px, so export at 1,400 to 1,600 px.
- Full-width banner: the one case where you do not double, because the cost in file size outweighs the visible gain — 1,920 px is almost always enough, with 2,560 px a sensible ceiling.
Beyond that, the visual gain becomes undetectable while the file size keeps climbing. The tool for resizing an image to an exact width does it in one pass, and the maths happens inside your browser: the file is never sent to a server.
Second habit, and the one most often forgotten: crop. Empty margins, a flat expanse of sky across the top third, a pointless border — those are pixels you are paying full price for.
Choose the format to match what is in the image
There is no “best format” in the abstract, only a format that suits each kind of content.
| Format | Made for | Avoid for |
|---|---|---|
| JPEG | Photographs, gradients, natural scenes | Screenshots, text, transparency |
| PNG | Screenshots, logos, flat colour, transparency | Photographs: 5 to 10 times heavier than the JPEG |
| WebP | Photos, flat colour, transparency, animation; read by every browser since 2020 | A print shop or an older piece of software |
| AVIF | The best compression at equal perceived quality | An audience on Safari older than 2022 or Edge older than 2024, with no fallback |
| SVG | Logos, icons, diagrams, charts | Any image that came out of a camera |
| GIF | Compatibility with an ancient system | Animation: 256 colours and an absurd file size |
The most common mistake by far is the misplaced PNG. A photo saved as PNG because “it looks cleaner” easily runs to 2 or 3 MB where the equivalent JPEG would be 250 to 400 KB: being lossless, PNG faithfully encodes every speck of sensor noise. The reverse case, a screenshot pushed through JPEG, produces greyish halos around the letters. The converter between JPG, PNG, WebP, GIF and BMP lets you produce two versions of the same file and compare the sizes before you commit.
One special case: iPhone photos in HEIC. Only Safari displays them, and only from version 17 onwards; Chrome, Edge and Firefox cannot read them, and most content management systems reject them on upload. You need to convert them to JPG before doing anything else.
Setting quality without visible damage
For JPEG, the useful band sits between 75 and 85. Above 90 the file size explodes for a gain the eye cannot see. Below 65, the 8 × 8 pixel blocks the algorithm works in start showing up in skies and gradients, and halos form along sharp edges. For lossy WebP, a quality of 75 to 80 gives roughly the look of a JPEG at 85 in a lighter file.
Two settings make a real difference:
- Chroma subsampling. The 4:2:0 mode, applied by default, halves the resolution of the colour information in each direction — four times fewer colour samples than pixels. Invisible on a photograph, but red text on a white background comes out smeared. For an image containing text or a logo, choose 4:4:4, or switch to PNG or WebP.
- Progressive JPEG. The image appears coarse at first and then sharpens, instead of painting itself line by line. Above roughly 10 KB it is more pleasant to use and often slightly lighter.
For a PNG, quality is not a setting at all: everything hangs on the palette. Putting a flat-colour image back through PNG-8, meaning 256 colours, often halves the file size with no perceptible difference on a logo. On a photograph, the same move produces banding in the gradients.
Target sizes once the job is done: 20 to 50 KB for a thumbnail, 80 to 150 KB for an article illustration, under 250 KB for a banner. The module for compressing JPG, PNG and WebP images shows the size you end up with, so you can check straight away whether you are in the right ballpark.
The traps that add weight where you cannot see it
- EXIF metadata. Camera model, settings, GPS coordinates and an embedded thumbnail: several tens of KB of dead weight, and a leak of information if the photo was taken at your home.
- The colour profile. An Adobe RGB or ProPhoto profile adds weight and shifts the colours wherever it is ignored. sRGB is still the only safe choice for the web.
- Lost transparency. A transparent PNG saved as JPEG has its background turn black or white, without the slightest warning. A logo meant to sit on a coloured surface has to stay PNG or WebP.
- Upscaling. Taking an image from 600 px to 1,600 px invents no detail whatsoever: it adds weight and blur.
- Repeated recompression. Every save of an already-compressed JPEG stacks fresh artefacts on top. Go back to the original, never to the file you have already published.
- Noise. High ISO, dense foliage, gravel: noise is random, and therefore all but incompressible. It is often the explanation for a file that stays heavy despite sensible settings.
The file is only half the job: the markup counts just as much
A perfectly compressed image can still drag a page down. Three things to check on the HTML side:
- Set the width and the height on every image tag, or an aspect ratio in CSS. Otherwise the browser reserves no space and the text jumps when the image lands.
- Serve several sizes through srcset, with sizes to describe the real display width. A phone will then download the 800 px version instead of the 1,600 px one.
- Defer whatever sits below the fold, but never the main image at the top of the page: putting that one on lazy loading delays it and hurts Largest Contentful Paint, whose threshold for a good score is 2.5 seconds.
When the result is not good enough
If the image is still heavy after compression, it holds too many pixels or too much noise: drop the width another notch rather than lowering the quality again. If the colours have shifted, the colour profile is to blame: convert back to sRGB. If the result looks soft, you pushed the quality too low or resized twice in a row: start again from the original. And if the file is rejected on upload, check what it actually is — a file renamed to .jpg that is really a HEIC will be turned away.
Resizing, cropping, format conversion and compression all run entirely inside your browser on Convertu: nothing is transmitted, nothing is stored. Those four tools do require an account and are covered by the subscription at €7 a year, as is HEIC conversion, which goes through a server with one free conversion every day and no sign-up.