Responsive images with srcset and sizes

What it means

The image's slot is the space it occupies in your layout, measured here in CSS pixels. The source file has separate pixel dimensions. Responsive images let the browser choose a resource suited to that space without requiring the layout itself to change.

The useful distinction is between display size and source resolution. A higher-density display can call for more source pixels across the same CSS-width slot. That is why making an image look smaller and making a smaller resource available are different operations.

Try it

Example: start with CSS display width (px) = 320 and Device pixel ratio = 2. Change Device pixel ratio to 1, then select Compare with baseline to see how the target changes. The initial example remains readable without JavaScript; the controls require JavaScript and perform no external action.

Target candidate width ≈ 640px. A 320px CSS slot at DPR 2 suggests approximately 640 physical pixels for a sharp source; selection remains browser-specific.

Keep CSS display width at 320px. Change only Device pixel ratio, so the comparison isolates density demand rather than a layout-width change.

Reset restores CSS display width to 320px and Device pixel ratio to 2, removes input errors, and clears the comparison. It preserves your independently opened or closed FAQ answers and About this model disclosure.

How it works

The supplied escaped text-code example assumes a 320 CSS-pixel-wide slot and two prepared versions of the same meaningful image, exactly 320 and 640 pixels wide. Its illustrative paths are not resources that this lab fetches.

The example declares src="diagram-320.png", srcset="diagram-320.png 320w, diagram-640.png 640w", sizes="320px", width="320", height="180", and alt="A request passing from a browser to a server". These are the attributes shown in the accompanying code example, not an executable image embedded by this explanation.

The browser can interpret a width-described candidate by dividing its declared resource width by the declared slot width. Here, 320w ÷ 320px gives an effective density of 1x, while 640w ÷ 320px gives 2x. That intermediate density connects the available files to the device's density needs: at DPR 2, the 640w candidate matches the simple target.

The lab expresses the same relationship in the other direction: CSS slot width × DPR gives a target source width. It calculates demand, not a selected filename. The browser can consider density, zoom, and other conditions when choosing among resources, so a matching target does not guarantee a particular selection.

The sizes value informs selection; it is not a CSS rule that forces the rendered width. Likewise, the example's width and height attributes provide dimensions and an aspect ratio, while CSS can still affect layout. If the declared slot and the actual layout disagree, the browser's sizing information can describe a different need from the one the image really has. Checking that agreement is more useful than changing descriptors until a preferred filename appears.

Worked example

This is a synthetic baseline, not a captured browser observation.

The target aligns with the prepared 640w candidate under the example's declared 320px slot. It does not establish that the browser fetched diagram-640.png.

A separate supplied arithmetic case uses 375 CSS pixels at DPR 1.5: 375 × 1.5 = 562.5px. That fractional target is still only an estimate of demand, not evidence of a file exactly 562.5 pixels wide or an observed resource selection.

What changes when the condition changes

Change Device pixel ratio from 2 to 1 while keeping CSS display width at 320px. The result becomes Target candidate width ≈ 320px.

The layout has not become narrower. Instead, the density target falls from two source pixels per CSS pixel to one, so 320 × 1 = 320 rather than 640. In the supplied candidate set, 320w now matches that simple target. This does not guarantee that the browser switches files or that download size is halved.

In practice

Use a local or staging copy that you are authorized to edit, with a browser that supports responsive images and developer tools for inspecting layout and the selected resource. This is a workflow for one image, not a site-wide optimization or production deployment procedure.

1. Read-only preflight: inspect the image's rendered CSS width at representative narrow and wide viewports. Check each candidate's actual pixel width and path, and compare the current sizes declaration with the intended layout. STOP before editing if you cannot establish the dimensions, the paths are missing, the declared slot contradicts the layout, or you lack permission to make the change.
2. Preserve and scope: save the previous markup and assets. Limit the edit to this image's source configuration and prepared same-content variants. Keep its intended layout, meaningful alternative text, and suitable src fallback. Write width descriptors from the files' actual widths, not their filenames. Use sizes to describe the intended slot; add media conditions when the layout requires different slot sizes.
3. Verify in the browser: inspect the rendered width and selected resource in the same representative viewports and relevant density conditions. Expect an intended image URL, the intended layout, and a legible image—not a guaranteed file switch or new request on every resize. If the image is missing, a descriptor misstates its width, or selection information no longer matches the layout, STOP and correct the local or staging copy before considering publication.
4. Verify rollback if needed: if the change regresses the page, restore the saved markup and assets. Recheck the image, layout, and selected resource under the same conditions to confirm that the previous behavior has returned. Any later production change requires the applicable authorization and its own verification.

Limits and unknowns

This is a local Example, not a live browser check. It does not access your files, download the illustrated candidates, detect your device pixel ratio, or inspect a deployed page. A valid result establishes only the product of the two supplied numbers. The actual selected URL, transferred bytes, and image quality remain unknown without evidence from the real page and browser.

CSS display width supports 1–2000px; device pixel ratio supports 1–4, with a displayed increment of 0.25. If an input is empty or invalid, no calculated outcome applies until you correct it or use Reset; an older valid result is not retained as the current answer.

The model cannot check whether sizes matches your CSS layout or whether a width descriptor matches its file. Those mismatches matter: even correct multiplication can be based on the wrong slot width. This page covers candidate selection, not a complete image-compression or performance assessment.

What to carry forward

Keep three things separate: the width your layout displays, the dimensions your source files actually have, and the sizing information you declare for selection. When those agree, the density estimate helps explain candidate suitability. If a real page behaves unexpectedly, inspect those inputs and the selected resource before changing the markup; the estimate alone cannot diagnose the choice.