Image Sizes for the Web: Dimensions and Weight

Two numbers describe an image, and people often confuse them. Dimensions are the pixel width and height (say 1600×1067); file weight is how many kilobytes it takes to store (say 180 KB). Dimensions determine how big the picture can be displayed sharply; weight determines how long it takes to download. Compression reduces weight without changing dimensions, while resizing reduces both. Fast pages need both under control.

As practical starting points: full-width hero images around 1600–2000 pixels wide; in-article content images around 1000–1600 pixels; thumbnails and avatars 150–400 pixels. Because many screens are high-density ("Retina"), exporting at roughly twice the displayed size keeps images crisp on those devices. There is no benefit to a 4000-pixel image in a 800-pixel slot — the browser just downloads data it immediately discards.

Two is the right multiplier to stop at. A 3× phone display really does have three device pixels per CSS pixel, but the extra detail is close to invisible at normal viewing distance, while the cost grows with the square of the scale — 3× means 2.25 times as many pixels as 2×. Capping at 2× and spending a few of the saved bytes on a slightly higher quality setting looks better per kilobyte than shipping a huge 3× file. For logos, icons and simple diagrams, SVG avoids the question completely: it is resolution-independent by definition.

Rather than guessing one compromise size, give the browser a choice. A srcset list offers the same picture at several widths, each labelled with its real pixel width, and a sizes attribute describes how wide the slot will be at each breakpoint — for example the full viewport on phones and 700 pixels on desktop. The browser combines the two with the device pixel ratio and downloads exactly one file, the smallest one that will still look sharp.

Three or four widths are usually enough — something like 400, 800, 1200 and 1600 pixels. The common mistake is the sizes attribute: leave it out and the browser assumes the image fills the viewport, so it over-fetches on wide desktop screens and quietly undoes the whole exercise. Write sizes to match your actual layout, and re-check it whenever the layout changes.

Always set the width and height attributes on an image, even when CSS controls the displayed size. The browser uses the ratio between the two to reserve the right amount of space before a single byte of the file arrives, so the text below does not jump when the picture appears. Unsized images are one of the most common causes of a failing Cumulative Layout Shift score, and CLS is a Core Web Vital alongside Largest Contentful Paint.

The numbers do not have to match the CSS size; only their ratio matters. A 1600×900 file displayed 700 pixels wide still reserves a correct 16:9 box, and modern browsers keep that ratio as the column resizes.

For weight, aim to keep most content images under about 200 KB and hero images under roughly 300–400 KB; thumbnails should be a few dozen kilobytes at most. This matters directly for SEO: Google's Core Web Vitals include Largest Contentful Paint, which is often your hero image, so a lighter hero literally improves your ranking signal. Resize to the right dimensions first, then compress with a before/after check, and a typical page can shed megabytes without any visible change.

It helps to think in page budgets rather than per-image rules. A reasonable target for a content page is under about 1 MB in total, with images accounting for no more than roughly 600 KB of it — so an article with ten pictures cannot afford 200 KB each. Open the browser's network panel, sort by size, and look at the top of the list: one forgotten 3 MB background is a far more common cause of a slow page than ten slightly heavy photos.

Everything below the fold should carry loading="lazy", so it is fetched only as the reader approaches it; on a long article that alone can halve the bytes actually transferred. The image at the top is the opposite case: it is usually the Largest Contentful Paint element, so it must not be lazy, and marking it fetchpriority="high" moves it ahead of scripts and other images in the download queue. One high-priority hero and lazy everything else is most of the win.