Images for the Web: Resize, Compress, Convert

Three steps, and the order is the point

A photograph straight off a phone, or an export straight out of a design tool, is usually wrong for the web in three separate ways at once. It has far more pixels than the page will ever show. It is encoded more generously than anyone can see. And it is in a format chosen by whatever produced it rather than by you.

Three different fixes, and they are not interchangeable:

• Resizing changes the pixel dimensions. A picture 4000 pixels wide becomes 1200 pixels wide.
• Compressing changes how many bytes those pixels cost. Same 1200 pixels, smaller file.
• Converting changes the format doing the encoding. JPEG or PNG becomes WebP.

Nearly every guide to this lists all three. Far fewer say what order to do them in, and the order is where most of the result comes from.

Resize first, because pixel count is the multiplier on everything that follows. Halving the width and the height leaves a quarter of the pixels, so the compressor then has a quarter as much work to do, and quality decisions you make afterwards apply to the pixels you are actually keeping.

Then encode once. This is the part worth internalising: every lossy save discards detail permanently, and a second pass cannot recover what the first one threw away, it can only throw away more. Compressing a photo and then resizing it means the file is re-encoded a second time, so you have paid the lossy toll twice to arrive at the same dimensions. Converting an already-compressed JPEG to WebP has the same problem from the other end: the JPEG's artifacts are now part of the picture, and WebP faithfully encodes them along with everything else.

So the honest version of the three steps is: resize to the size you will serve, then make one lossy encode in the format you intend to serve. Compressing and converting are usually a single operation, and that is a feature, not a shortcut. The image compressor sets the output format and the quality in the same pass for exactly this reason.

Step one: resize to the slot it will sit in

Start by finding out how wide the image is actually displayed. Open the page, right-click the image, inspect it, and read the rendered width. That number, not the original file's width, is what everything else is based on.

Then double it. Most phones and laptops now pack two or three device pixels into each CSS pixel, so an image shown in a 600 pixel column looks soft unless the file itself is around 1200 pixels wide. Export at roughly twice the display width and compress harder to pay for it: a 1200 pixel file at quality 70 usually beats a 600 pixel file at quality 90, both in appearance and in bytes.

There is a ceiling, though. Past about twice the display size the extra pixels stop being visible and only cost download time. Three times is worth it for logos and line art on very dense screens, and almost never for photographs.

The one case where doubling breaks down is a full-bleed hero. A hero that spans a 1920 pixel desktop window is already asking for a large file, and a true 2x version of it would be 3840 pixels wide for a picture most visitors will see on a phone. Cap it somewhere around 2400 and accept that it is not quite 2x on a large dense display. Nobody has ever noticed this. Everybody notices a 2 MB hero on mobile data.

Useful starting widths, assuming a 2x export:

The image resizer takes one dimension and works out the other with the ratio locked, which is the setting you want on by default: unlocking it is how pictures end up subtly stretched.

If the shape is wrong as well as the size, crop before you resize. Cropping removes pixels from the edges and leaves the rest untouched, so doing it first means you are not scaling pixels you are about to discard, and you keep control of what gets cut. Platforms that crop for you take the centre of the frame, which is very often not where the subject is. The photo cropper does the shape, then the resizer does the exact dimensions.

Step two: encode at the size you will actually serve

With the dimensions settled, quality is one decision and it is less agonising than it looks.

Quality 80 is the usual place to land for photographs. Between 70 and 85 files shrink dramatically while the artifacts stay invisible at the size a page displays them. Below about 60 they start to show, and they show first in skies, gradients and skin tones, because those are the smooth areas where a lossy encoder has the least detail to hide behind. Go lower than that only for thumbnails, where nobody is looking closely.

Two things make the slider behave differently from how people expect.

The number is a setting, not a measurement. Quality 80 in a JPEG encoder and quality 80 in a WebP encoder do not mean the same amount of quality, and two tools at the same nominal setting can produce visibly different files. Judge the output, not the number.

What is in the picture matters more than the setting. A photograph holds millions of slightly different pixels and gives up two thirds to four fifths of its weight at quality 80, with nothing visible at the size a page shows it. A screenshot of text, a logo or a flat graphic behaves in the opposite way: large areas of identical colour, which JPEG handles badly, smearing the edges of letters, and which lossless formats handle very well. For anything with crisp edges and flat fills, stay lossless: PNG, or lossless WebP, which MDN puts at around 26% smaller than the equivalent PNG.

And start from the original whenever you still have it. A file that has already been squeezed by another tool has little left to give, and squeezing it again mostly just costs quality.

Step three: convert, and keep a fallback

For photographs, WebP is the default worth reaching for. Google's own comparison study puts WebP at 25% to 34% smaller than JPEG at the same structural similarity index, which is a saving you get for changing nothing except the container.

Support is no longer the question it was. MDN lists WebP as supported in all current versions of Chrome, Edge, Firefox, Opera and Safari, with the only real caveat being that Safari on macOS needs version 14 and Big Sur or later. Google Search reads WebP in an img src too, alongside BMP, GIF, JPEG, PNG, SVG and AVIF, so converting does not cost you image search.

The way to serve it without betting the page on format support is a picture element:

<picture>
  <source srcset="/images/workshop-floor.webp" type="image/webp">
  <img src="/images/workshop-floor.jpg" alt="Printing press mid-run on the workshop floor"
       width="1200" height="675" loading="lazy" decoding="async">
</picture>

The WebP converter goes both ways, which matters more often than you would think. Some older software, printers and upload forms still refuse WebP, and converting back to JPG or PNG is how you make a file universally accepted again.

What about AVIF? It does compress better: MDN puts it at a median 50% smaller than JPEG against WebP's 30%. The trade-offs are real, though. Support arrived later (Chrome 85, Firefox 93, Safari 16.1, Edge 121), encoding is much slower, and AVIF has no progressive rendering, so the file has to arrive completely before anything appears. WebP is the pragmatic default; AVIF is a further optimisation to add on top, behind the same picture element, not a replacement for the step above.

When the target is a file size, not a web page

Forms and portals change the problem. An application site that demands a photo "under 100 KB" does not care about your display width, and nudging a quality slider towards a number is a slow way to find the answer.

Give the target to the tool instead. Compress image to target size binary-searches the quality to land just under the number you name, and scales the dimensions down if quality alone cannot get there. Two things to know before you use it: a 100 KB target typically produces a 90 to 99 KB file, because under is the point, and a PNG comes back as a JPG, because a lossless format cannot be pushed to an arbitrary size.

If the form also specifies dimensions, do those first with the resizer or the cropper, then hit the size target. The other way round wastes the search.

What this site does with its own images

The blog you are reading is a reasonable worked example, because every number in it is checkable by right-clicking an image.

Each post's illustration is exported once at 3840 pixels wide and kept as the master. From that one file the build cuts the article hero at 800, 1200, 1600 and 2400 pixels as WebP at quality 82, plus a 1600 × 900 JPEG at quality 86 as the fallback, and the browser picks from a srcset. The 2400 version exists because the hero spans the full content column, which a 2x screen draws at roughly 2240 pixels.

The sizes that come out are a fair illustration of what the three steps are worth. On the post about link previews, the 2400 pixel hero is 53 KB as WebP, while the 1600 pixel JPEG fallback for the same picture is 90 KB: the wider modern file is the smaller download. The 800 pixel version a phone receives is 13 KB. And that post's in-article illustration, a flat vector drawing 2400 pixels wide, is 890 KB as a PNG and 57 KB as WebP, which is what "flat colour suits WebP" looks like in practice.

Two details that are not about file size but travel with it. Every image carries width and height so the browser can reserve the space before the file arrives, which is what keeps the layout from jumping. And the hero is deliberately not lazy-loaded while everything below it is, because lazy-loading the largest image in the first screen delays the exact thing Largest Contentful Paint measures.

Four things that quietly go wrong

Transparency disappears. JPEG has no alpha channel, so transparent areas get filled, usually with white. If the logo has to sit on a coloured background, the output has to be PNG or WebP.

Metadata does not survive. Re-encoding writes a fresh file, so camera EXIF, GPS coordinates and embedded colour profiles are left behind. That is usually a privacy gain, occasionally a loss if you needed the shot data, and worth knowing either way before you publish a customer's photograph.

The filename is doing work. Google asks for filenames that are short but descriptive, and my-new-black-kitten.jpg genuinely is better than IMG00023.JPG. The same habit has a second payoff: when you replace an image, change the filename too, because platforms cache link preview images by URL and will keep showing the old one otherwise.

Image weight is not always the bottleneck. This is worth saying out loud, because image guides tend to promise more than they deliver. Google's own LCP guidance notes that resource load duration tends not to be a significant bottleneck for most sites, and asks you to look at your own real-user data before prioritising it. The target to beat is an LCP of 2.5 seconds for 75% of visits. If your pages miss it with light images, the cause is somewhere else, and we have written about the four usual somewhere-elses, one of which cost us 1.5 seconds on our own homepage for the most embarrassing possible reason.

The five-minute version

1. Find the width the image is displayed at, and double it. Cap a full-bleed hero around 2400.
2. Crop to the shape you want with the photo cropper if the framing is wrong.
3. Resize to that width with the image resizer, ratio locked.
4. Make one lossy encode with the image compressor: quality 80 for photographs, lossless for screenshots, logos and anything with text in it.
5. Output WebP, or convert an already-sized file with the WebP converter, and keep the original format as a fallback in a picture element.
6. If a form named a byte limit instead, use compress image to target size and let it search.

Every tool linked above runs in the browser, on your device. The images are never uploaded to us, which is also why they are fast. If you want to confirm that for yourself rather than take our word for it, the no-upload test is three checks you can run on any online tool, this one included.

Images are the first place to look when a site feels slow, and the easiest thing to fix without touching any code. If the pictures are the problem and nobody has the time, that is website fixes and maintenance; if the pictures are fine and the pages still are not being found, that is SEO.