How to shrink images for the web without them looking bad
6 min read · Measurements taken 2026-08-09
Images are usually the largest thing on a web page, and the difference between a photo straight off a phone and the same photo prepared properly is often a factor of fifty. The order of operations matters more than any single setting.
The short version
Resize first, compress second, choose the format last. Doing it in that order on our test landscape takes it from 2.2 MB as a lossless original to well under 40 KB, with nothing visibly wrong at the size it is actually displayed.
Step 1: work out the size you actually need
Most oversized images on the web are oversized because nobody asked this question. A photo displayed in a 700-pixel-wide article column does not need to be 4000 pixels wide. The browser will scale it down for display, but the visitor still downloads every byte of the original.
Find the widest the image is ever displayed, then double it for high-density screens. An article image shown at 700px should be around 1400px wide. A full-width hero might be 2400px. A thumbnail shown at 200px needs 400px.
Why doubling is enough
Phone and laptop screens pack two or three physical pixels into each CSS pixel. Supplying double resolution covers the common 2× case and looks fine on 3× displays, because at that density the remaining difference is beyond what most people can resolve. Going to 3× triples the pixel count for almost no perceived gain.
Step 2: resize before compressing
This ordering is not arbitrary. Compressing at full size and then scaling down wastes the work — you carefully encoded detail that is about to be thrown away, and the scaling then re-introduces softness that the compressor already fought.
Resizing first also makes the quality setting mean something. When the image is already at display size, quality 80 refers to artefacts at the size people actually see, not artefacts in a version that will be shrunk afterwards.
Our landscape photograph at full 1920px width is 84 KB as WebP quality 80. Scaled to a 1200px article width first, the same settings land somewhere near 33 KB, because file size scales roughly with pixel count and the resize removes about 61% of the pixels. The resizer uses Lanczos resampling, which we measured as 41% more accurate than the browser default on this photograph.
Step 3: pick the format for the content
For photographs, WebP. Our landscape was 186 KB as JPEG quality 80 and 84 KB as WebP at the same setting — a 55% saving for no visible difference.
For screenshots, diagrams and anything containing text, PNG or WebP — never JPEG. Our synthetic screenshot was 4× larger as JPEG than as lossless PNG, and blurrier. The format comparison has the full table.
Step 4: set quality by result, not by habit
Use 75–85 for photographs. Below about 60 you start seeing blocking in flat areas like skies; above 90 the file grows steeply for changes nobody can see. The compressor shows the resulting file size as you move the slider, so if you have a budget — under 150 KB per image, say — you can hit it directly instead of guessing.
Doing it for a whole site
For a folder of images, the same order applies but you only want to set it once. Bulk resize fits every image inside your target dimensions while preserving each one’s aspect ratio, then bulk compress applies one format and quality to the batch and shows the saving per file.
If you want both steps in one pass, the editor applies a whole recipe of operations across a batch and exports the results as a ZIP — and because it re-runs your steps from each original rather than re-encoding after every change, the image is only compressed once at the end.
Things that quietly bloat images
Screenshots saved as JPEG. Covered above, and worth repeating because it is so common.
Exporting at quality 100. On our test images this cost between 40% and 240% more than quality 90 for no useful gain.
PNG for photographs. 2.2 MB against 186 KB for the same picture — roughly 12× the bytes.
Uploading straight from a phone. Modern phone cameras produce 12-megapixel-plus files. Almost no web context needs that.
How we measured this
The figures here come from the same run as our other guides: seven images encoded through Chromium’s canvas encoder at every quality level, plus downscaling accuracy measured against an exact area-average ground truth. The resized-size estimate above is derived from pixel-count scaling rather than measured directly, and is marked as approximate for that reason. Method and image sources are listed in the format comparison.