The width to export, and why the browser will not fix it for you

Two kinds of pixel, and the number in between

A layout is written in CSS pixels, which are a unit of apparent size, not of hardware. A phone that reports a 390-pixel-wide viewport has around 1170 physical pixels across the glass. The ratio between them is the device pixel ratio, and it is 1 on an old monitor, 2 on most laptops and mid-range phones, and 3 on many flagship phones.

That is the whole of the sizing arithmetic. An image displayed in a 600 CSS-pixel column needs 1200 real pixels to be crisp on a DPR 2 screen.

export width = CSS width of the slot x device pixel ratio

Work out the CSS width honestly. It is not the width of the page, it is the width of the box the image sits in at the breakpoint you care about, which is usually the phone, because that is where most of the traffic is and where the data costs money.

Stop at 2x

You could export at 3x for the DPR 3 phones. Almost nobody should.

A 3x file has 2.25 times the pixels of a 2x file, and therefore roughly 2.25 times the bytes. The visible gain over 2x on a screen held at normal reading distance is at the edge of what most people can detect, because at that pixel density the limit is your eye rather than the file. Some teams do serve 3x for logos and line art, where the hard edges do show it, and 2x for photographs. That is a defensible split.

The opposite mistake costs more. A 4000-pixel photograph dropped into a 600-pixel column is around 40 times the necessary data, and on a slow connection it is the difference between a page that loads and a page somebody leaves.

What the browser does with a mismatch, and why it is not free

Give a browser an image larger than the slot and it will scale it down. People take this as a reason not to worry. Three reasons to worry:

It downloads all of it first. The scaling is free. The bytes are not.

The downscale is not gamma-correct. Browsers resample in encoded space, so the darkening described in the resampling lesson applies to every oversized image you hand them, most visibly on fine bright detail.

There is no output sharpening. Your sharpening was tuned for the size you exported. Shrunk by an arbitrary factor in the browser, it is either invisible or crunchy. Resize to the delivered size yourself, then sharpen, and the result is noticeably crisper than the same photograph delivered oversized, at a fraction of the bytes. This is the single most common reason a site’s images look slightly soft.

The mirror-image mistake is an image smaller than its slot, which the browser enlarges by interpolation with no detail to work from. A 400-pixel logo in an 800-pixel header is soft, and no CSS fixes it.

Numbers that are actually useful

These are starting points for a typical content site, at 2x, before you measure your own layout:

• Full-bleed hero on a phone: 800 to 1000 px wide. On a wide desktop layout, 1600 to 2000.
• Article body image in a readable text column: 1200 to 1400 px.
• Card or grid thumbnail: 600 to 800 px.
• Avatar at 48 CSS px: 96 px, and not one pixel more.
• Product image with a zoom feature: the zoom is the constraint, not the page. 2000 px square is the common floor.

Measure rather than guess. In any browser, right-click an image, Inspect, and the element panel shows both the natural size and the rendered size. If the natural width is more than about 2.5 times the rendered width, you are wasting somebody’s data.

Aspect ratio, and the shift nobody notices until it ships

Export at the ratio the slot uses. If the layout crops a 3:2 photograph to 16:9 with object-fit: cover, the crop happens at the centre by default and it will cut heads off. Either crop deliberately in the editor and export at the target ratio, or set object-position so the crop favours the part that matters.

Always give the image element its width and height attributes, even when CSS resizes it. The browser uses them to reserve space before the file arrives, and without them the page jumps as each image loads: the thing that makes you tap the wrong link on a phone.

The free route

None of this needs a paid tool. GIMP’s Image > Scale Image, Photopea’s Image > Image Size, or one command:

magick in.jpg -colorspace RGB -filter Lanczos -resize 1200x -colorspace sRGB \
  -unsharp 0x0.6+0.7+0.02 -quality 82 -strip out.jpg

Resize, sharpen at the delivered size, compress, strip metadata. That is the whole export in one line, and the order in it is the order from the sharpening lesson.

Today: open your own site or a page you made, inspect three images, and write down natural size against rendered size. The first number is usually three to six times the second, and each one of those is a file you can shrink today without anybody seeing a difference.