The Right Image Size for Every Use Case: A Web Resizing Guide

Uploading an oversized image does not make a page look sharper — it makes it load slower, on every visit, for every visitor. Browsers scale images down to fit their container, but they still download the full file first. Matching dimensions to where the image is actually used is one of the cheapest performance wins available.

The measured version of that claim: taking a 1600px screenshot down to 800px cut its WEBP file from 44.8 KB to 14.2 KB — a 68% saving, with the quality setting untouched. No compression tradeoff, no visible difference at the display size. Just fewer pixels.

Reference sizes by use case

The 2× rule, and when to ignore it

High-density screens pack two or more physical pixels into each CSS pixel, so an image displayed at 800px wide can look slightly soft if you export it at exactly 800px. The usual fix is to export at 2× and let the browser scale down.

Worth applying with some judgement, though. Doubling the width quadruples the pixel count, and for a photograph displayed small the sharpness gain is marginal while the size cost is not. Reserve 2× for images that are large on screen or contain fine detail — logos, text, product shots people will scrutinise. For a background image or a small thumbnail, 1× is fine.

Never upscale a small image

Stretching a 400px image up to 1200px does not add detail — it makes the file bigger while looking softer and slightly blurred. If an image is too small for where you need it, the fix is a better source image, not a resize tool. Resizing only removes information; it cannot invent it.

Crop before you resize when the aspect ratio is wrong

Forcing a 4:3 photo into a 1:1 square by squashing it distorts everything in the frame — faces stretch, straight lines curve. Crop to the target aspect ratio first, then resize to the final pixel dimensions. The order matters: cropping decides what is kept, resizing decides how big it is.

One size rarely fits every screen

A hero image that looks right on a 1920px desktop display is often several times larger than a phone screen needs. If your site supports responsive images, export two or three sizes — say 640px, 1200px, and 1920px wide — and let the browser pick. Phones then download the small version instead of the desktop one.

The mechanism is the srcset and sizes attributes on the img element. srcset lists the files you have and how wide each one is; sizes tells the browser how much space the image will occupy so it can choose before layout is complete. Getting sizes wrong is the usual reason srcset appears to do nothing.

Where the biggest image on the page is costing you

On most pages the largest visible element is an image, and how fast it appears is what Largest Contentful Paint measures. It is a Core Web Vital, which means Google uses it as a ranking input. An oversized hero image is the single most common reason a page fails it.

The fix is almost never clever. It is: export the hero at the width it actually renders, convert it to WEBP, and stop the browser discovering it late. That last part catches people out — an image loaded by CSS or injected by JavaScript is found only after the stylesheet or script has been parsed, so it starts downloading later than an ordinary img tag would. If an image is the largest thing on screen, put it in the markup.

Lazy loading deserves the same care in reverse. Marking images below the fold as lazy is straightforwardly good; marking the hero as lazy delays the very element LCP is timing. Load the first screen eagerly and lazy-load everything under it.

Retina, density, and why 3× is usually waste

Phone screens have run at 3× density for years, and it is tempting to export everything at three times the display size to match. In practice the returns fall off sharply after 2×. The eye stops resolving additional detail, while the pixel count — and therefore the file — grows with the square of the multiplier.

A 400px avatar exported at 2× is 800px and roughly four times the pixels. At 3× it is 1200px and nine times the pixels, for a difference almost nobody can see. Spend the 2× on images that are large on screen or contain text and fine detail; leave everything else at 1× or 1.5×.

Always set width and height

An image without declared dimensions has no size until it downloads, so the browser lays out the page without it and then reflows once it arrives. Everything below jumps. That is Cumulative Layout Shift, another Core Web Vital, and it is entirely avoidable.

Set the width and height attributes to the image's intrinsic pixel dimensions. The browser derives the aspect ratio and reserves the space, even when your CSS is going to resize it anyway. Every image on this site does exactly that.

A workflow that holds up

• Find the widest the image is actually rendered — inspect it in the browser rather than guessing
• Crop to the right aspect ratio first, so nothing gets distorted later
• Resize to that width, or 2× it if the image is large or detailed
• Convert to WEBP and encode at quality 85
• Set width and height attributes to the exported dimensions

The cheapest optimisation available is not compressing harder. It is shipping an image that was the right size to begin with.