Responsive Images With srcset: Serving the Right Size to Every Screen

A single image file cannot serve every screen well. A 2400-pixel-wide hero looks sharp on a desktop monitor but wastes most of its bytes on a phone, where it is displayed at 400 pixels wide. A 400-pixel image loads fast on a phone but looks blurry on a large screen. Responsive images solve this by offering the browser several versions of the same image at different widths and letting it choose the one that fits the display. The Responsive Image srcset Builder builds the srcset list, and understanding how the browser chooses is what makes the list effective rather than decorative.

The srcset attribute lists image files with their widths, for example image-400.jpg 400w, image-800.jpg 800w, image-1200.jpg 1200w. The w descriptor is the image's actual pixel width, not the size it will be displayed at. The companion sizes attribute tells the browser how wide the image will be displayed at different viewport widths, for example (max-width: 600px) 100vw, 50vw, meaning full viewport width on small screens and half on larger ones. The browser combines the two: it works out the display width from sizes, multiplies by the device pixel ratio, and picks the smallest srcset candidate that is at least that large. A phone with a 400-pixel-wide viewport and a pixel ratio of 2 needs an 800-pixel image for a full-width slot, so it picks the 800w candidate, not the 400w one, and that is correct, because a 400-pixel image on a 2x screen would look soft.

The number of candidates is a judgement call. Too few, and some screens get an image much larger than needed, wasting bytes, or much smaller, looking blurry. Too many, and you generate and store many near-identical files for little benefit. Three to five widths covering the realistic range usually suffice: a small version for phones, a medium for tablets and small laptops, a large for desktops, and optionally an extra-large for very wide or high-density screens. The widths should be spaced generously, roughly doubling or increasing by at least 50 percent each step, because candidates closer together than that rarely change which one the browser picks, and each extra candidate is a file to generate, store and cache.

Art direction is a separate concern from resolution, and srcset alone does not handle it. If a wide landscape crop works on desktop but a phone needs a tighter square crop that keeps the subject visible, that is a job for the picture element with media queries, not for srcset, which only swaps resolution, not composition. Many pages need both: picture for the crop change, srcset inside each source for the resolution choice. Keeping the two ideas separate prevents the common error of adding ever more srcset widths in an attempt to fix a cropping problem that widths cannot solve.

A worked example you can follow

Build a srcset for a content image displayed at full width on phones and at 600 pixels wide on desktops. The sizes attribute is (max-width: 600px) 100vw, 600px. Offer four candidates: 400w, 800w, 1200w and 1600w. Now trace the browser's choice for three devices. A phone with a 390-pixel viewport and a pixel ratio of 2 needs 390 × 2 = 780 pixels, so it picks the smallest candidate at or above 780, which is 800w. A tablet with a 768-pixel viewport and a pixel ratio of 2 needs 768 × 2 = 1,536 pixels, so it picks 1600w. A desktop with a 1440-pixel viewport and a pixel ratio of 1 displays the image at 600 pixels, so it needs 600 × 1 = 600 pixels and picks 800w.

Check the waste in each case: the phone downloads 800 pixels for a 780-pixel need, an excess of 20 pixels, or about 2.6 percent. The tablet downloads 1600 for a 1536 need, an excess of 64 pixels, about 4.2 percent. The desktop downloads 800 for a 600 need, an excess of 200 pixels, or 33 percent, which looks wasteful until you compare it with the alternative: serving the 1600w file to every device would make the phone download twice what it needs and the desktop nearly three times. The srcset list is not perfect for every device, but it keeps the excess small for the common cases and avoids the worst case, which is one huge file for everyone.

Verify the result in the browser. Open the page at several viewport widths, check the network panel for which candidate was actually downloaded, and compare it with your trace. If the browser consistently picks a larger candidate than you expected, the sizes attribute is probably wrong, most commonly because it describes a slot wider than the image really occupies. If it picks a smaller one, the image will look soft, and the sizes value is probably understating the slot. The network panel is the truth; the trace is the prediction, and they should agree.

Common mistakes to avoid

The most common mistake is omitting the sizes attribute, which makes the browser assume the image is full viewport width and download larger candidates than needed. A second mistake is listing widths that do not match the actual files, so the browser's choice is based on wrong data. A third mistake is generating too many near-identical widths, adding build complexity for no visible gain. A fourth mistake is using srcset to fix a cropping problem, which needs the picture element instead. A fifth mistake is forgetting high-density screens: a 400-pixel slot on a 2x phone needs an 800-pixel file, and a srcset that tops out at 400w will look blurry on exactly the phones that matter most.

Responsive images are a quiet performance win: the same page, the same layout, but each device downloads an image close to what it can actually display. Build the list, trace the choices, and check the network panel.

Frequently asked questions

What does the w descriptor mean? The image file's actual pixel width, which the browser compares against the needed pixels calculated from the sizes attribute and the device pixel ratio.

How many srcset widths do I need? Three to five, spaced generously, covering phones through large desktops, is enough for most images.

Does srcset help SEO? It helps performance, which affects user experience and loading signals, but the mechanism itself is about delivering the right file, not about ranking directly.

For related image help, see Image Format Guide, and pair this builder with the Image Format Converter and the LCP Element Analyzer when optimising a page's images. Describe the slot honestly, space the widths generously, and let the browser choose.