How to compress images for a website

Our 4.3 megapixel test photo went from 3.26 MB to 315 KB without its quality setting dropping below 85. The quality slider didn’t do that. Resizing did: fitting the photo within 1920 pixels threw away just over half its pixels, and the bytes fell almost in step. If you want to compress images for a website, pick the size first and the quality second, because the size decision is worth far more.

Resize first: the numbers from one photo

The photo is a 2816 by 1536 pixel JPEG of people, saved at high quality, the kind of file a phone or an image generator hands you. We ran it through our own tools on 23 September 2026 at different sizes and settings.

Compare pixels with bytes. At 1920 wide the photo keeps 2,010,240 of its 4,325,376 pixels, 46.5%, and the file at quality 85 is 49.7% of the full-size file at the same quality. At 1280 it keeps 20.7% of the pixels and 25.8% of the bytes. The encoder spends roughly the same bytes per pixel whatever the size, so every pixel you cut is a saving you get without touching quality at all.

The quality route to the same file size looks worse. Saving the full-size photo at 60 lands at 289,597 bytes, close to the 1920 version, but its quality score falls from 0.946 to 0.914, and a visitor still gets a picture with more pixels than the page will ever show in a 1,200 pixel column. You pay for detail that gets scaled away on arrival. And the detail you keep is worse.

Format matters less than the headlines suggest at the same slider number. WebP at 85 was only 2% smaller than JPG at 85 here, though it also scored higher, so the fair comparison is at equal quality; that work is in our AVIF, WebP and JPG measurements. AVIF was the smallest full-size file by a wide margin. It also took about 2 seconds to encode, against 0.4 for the JPG.

Two things this table doesn’t answer. We didn’t measure a resized photo saved as WebP or AVIF, so we can’t tell you how much the two savings stack. And 1920 isn’t always enough: a hero image that fills a 1,280 pixel wide layout on a screen with twice the pixel density wants something closer to 2560. The batch resizer has 2560 and 3840 presets for that reason, and it never enlarges a smaller image.

Screenshots break the rule. Resizing made ours bigger: a 1440 by 900 screenshot of a pricing page, scaled to 1280 by 800 and kept as PNG, grew to 157% of its original size; a text-heavy page scaled to 960 by 1280 grew to 136%. Scaling blends flat colours and sharp text edges into many new in-between shades, and PNG compresses those badly.

Saving them as WebP at 85 instead cut the same two files by 55% and 51%, with higher quality scores than JPG at the same setting. For screenshots, interface images and logos, go to PNG to WebP before you reach for the resizer.

If you’re unsure where to set the slider after resizing, our JPG quality tests show where the file size starts climbing faster than the picture improves.

What real pages ship

On most sites, the biggest thing in the first screen is a picture. The 2024 Web Almanac found an image was the Largest Contentful Paint element on 73.3% of mobile pages and 83.3% of desktop pages. JPG was the format on 61% of them, PNG on 26%, WebP on 7% and AVIF on 0.3%. On mobile, 48% of pages had an LCP image between 100 and 200 KB, and 8% of pages on both mobile and desktop had one over 1000 KB.

Our 1280 version, at 164 KB, would sit in that common bracket. The untouched original would be in the heaviest 8% more than three times over.

Google’s target for LCP is 2.5 seconds or less for at least 75% of page visits.

Smaller images won’t rescue a slow server

The same Web Almanac chapter splits LCP time into parts, and image download was the smallest of them: 350 milliseconds at the 75th percentile for sites with poor LCP. Those sites spent 2.27 seconds on time to first byte alone. That is six times as long. A 3 MB hero on a mobile connection is still worth fixing, and it may be the reason your own page is slow. But advice that treats compression as the cure for a bad LCP score is wrong for most slow pages, where the wait happens before the image has even been requested.

We measured bytes. We haven’t measured LCP on a live site with these files, so we can’t tell you how many milliseconds the drop from 3.26 MB to 315 KB saves on a given phone or connection.

How Lighthouse decides an image is too big

Its “Efficiently encode images” audit collects the JPEG and BMP images on a page, re-encodes each at quality 85, and flags any where that would save 4 KiB or more. Two consequences follow. A photo saved as PNG isn’t checked by that audit at all, however wasteful it is. And a JPG already saved at 85 by a good encoder should have little left for the audit to find; our resizer defaults to the same 85. We haven’t run Lighthouse on the files above to confirm they pass.

A whole folder in one pass

Our batch compressor took six test images, 5.75 MB in total, down to 2.16 MB in 4.8 seconds at its default quality of 75. The two JPEG photos lost 88% and 89%. The four PNGs lost only 4% to 31%, because they stay PNG and are repacked without loss. Times are from a fast laptop. We haven’t timed a phone. If your site builder caps uploads at a set size, compress to a file size instead: it keeps the highest quality that fits under the limit and shrinks the image only when quality alone can’t get there.

1. Resize to the widest the layout will show the image, times the screen density you care about.
2. Save photos as JPG at 75 to 85, or WebP.
3. Save screenshots and graphics as WebP, not a smaller PNG.
4. Check the hero image lands near 200 KB or under; ours did at 164.
5. Then look at your server response time, which the image work above won’t touch.