What the Responsive Image srcset Builder does
This builder writes the srcset, sizes and <picture> markup for a responsive image from the widths you generate and the way the image is laid out, then shows which file a phone, tablet or desktop screen at 1x, 2x and 3x pixel density will typically download. It flags widths that leave a gap, files that are too small for large screens, and missing alt text or dimensions.
Responsive images go wrong quietly. A sizes value of 100vw on an image that actually fills a third of the page makes desktop browsers download files three times wider than needed; a width list that stops at 800 pixels makes the same image blurry on a high-density laptop. Neither shows up as an error - just as wasted bytes or soft pictures - so a preview of the actual choice is the quickest way to catch them.
How to use it
- List the widths you will produce, in pixels. If you are not sure, enter the sizes first and press Suggest from layout: it proposes widths from the smallest slot at 1x to the largest at 2x, in steps of about 1.5x.
- Describe how wide the image is displayed with
sizes: media conditions in order, first match wins, ending with a plain fallback.(min-width: 1280px) 300px, (min-width: 768px) 33vw, calc(50vw - 24px)means a fixed 300 px column on large screens, a third of the viewport on tablets and half the viewport minus the gutter on phones. - Set the file naming pattern, alt text, intrinsic width and height, the modern formats you produce and how the image should load: lazy for images below the fold, high priority for the image that is likely to be the Largest Contentful Paint.
- Copy the HTML, JSX or plain img markup, and the list of files the markup refers to.
- Check the preview table and findings: every viewport and density combination should get a file that is sharp enough without being much bigger than needed.
Reading the results
Slot width is what sizes evaluates to at that viewport; pixels needed is slot width times the device pixel ratio. The browser receives each candidate's width through the w descriptor and works out its density on that screen.
The HTML specification deliberately lets the browser choose any candidate - it may pick a smaller one on a slow or data-saving connection, or reuse a larger one already in its cache. The preview shows the common behaviour: the smallest file with at least the pixels needed, or the largest file when none is big enough. "Too small" means the image will be upscaled there.
Extra pixels is how much larger the chosen file is than needed, by area. Some overshoot is unavoidable with a finite list; above +100% there is a gap worth filling with an intermediate width.
Worked example: a four-column product grid
The Product grid example generates 320, 480, 640, 960 and 1280 pixel files and uses sizes="(min-width: 1280px) 300px, (min-width: 768px) 33vw, calc(50vw - 24px)". On a 414 px phone the second condition does not match, so the slot is 414 / 2 - 24 = 183 px. At 2x that needs 366 pixels, and the smallest file with at least that is the 480w one.
On a 1024 px tablet the slot is 33% of 1024 = 337.9 px; at 2x it needs 676 px and gets the 960w file, 101% more pixels than needed - the finding suggests an intermediate 700w or 800w file. On a 1440 px desktop the first condition applies: a fixed 300 px slot, 600 px at 2x, which the 640w file covers with only 14% to spare.
Had sizes been left at 100vw, the same 1440 px 2x screen would have asked for 2,880 pixels and downloaded the 1280w file - about 4.5 times the 600 x 600 pixels a 300 px card needs at 2x.
Formulas and scoring rules
- Slot width
slot = first matching sizes entry evaluated at the viewport widthvw is 1% of the viewport; em and rem are taken as 16 px.- Pixels needed
need = slot x device pixel ratio- Typical choice
chosen = smallest width >= need, else the largest width- Extra pixels
extra = (chosen / need)^2 - 1By area, which tracks file size roughly. Shown as a whole percentage.- Suggested widths
w(k) = min slot x 1.5^k, rounded to 10 px, up to 2 x the largest slot (max 4096)
Limitations: what the result does not prove
- Only
min-widthandmax-widthmedia conditions and vw, px, em and simplecalc()lengths are simulated. Other conditions, container units andsizes="auto"are reported rather than guessed. - The choice shown is typical browser behaviour, not a guarantee; network conditions, data-saver settings and the cache change it.
- The tool writes markup; it does not resize or encode images. Every file in the generated list must exist, in every format, or the browser will show a broken image.
- Whether AVIF or WebP is actually smaller for a given photo depends on the image and the encoder settings; measure a few before converting a whole library.
Privacy: where your data goes
Everything you paste, type or drop is processed in this browser tab. It is not uploaded, logged, stored or sent to analytics. Session recording and tag-manager scripts are switched off on this page.
Standards and sources
- HTML - img srcset and sizes - checked 19 Sep 2026
- MDN - Responsive images
- web.dev - Optimize Largest Contentful Paint
- web.dev - Browser-level image lazy loading
Frequently asked questions
What is the difference between srcset and sizes?
srcset lists the files and their widths, so the browser knows what it can choose from. sizes tells it how wide the image will be displayed at each viewport, before the CSS has loaded. The browser combines the two with the screen's pixel density to pick a file.
Do I need sizes if I use width descriptors?
Yes. Without sizes the browser assumes 100vw, so an image in a narrow column is treated as full width and a much larger file is downloaded. With x descriptors (1x, 2x) sizes is not used, but those only suit images with a fixed displayed size.
How many image widths should I generate?
Usually four to eight. Enough that neighbouring widths differ by around 1.5 times, covering the smallest displayed size at 1x up to the largest at 2x. Beyond that the markup grows and storage multiplies for very small savings.
Should the LCP image be lazy loaded?
No. Lazy loading waits until layout shows the image near the viewport, which delays the largest paint. Load the hero image eagerly with fetchpriority="high", and lazy-load images further down the page.
Why include width and height on a responsive image?
The browser uses their ratio to reserve the right amount of space before the file arrives, preventing layout shift. With CSS such as width: 100%; height: auto the image still scales; the attributes only need the correct aspect ratio.
Why does a picture element list AVIF before WebP?
The browser uses the first source whose type it supports, so the most efficient format goes first and the img element at the end is the fallback for browsers that support neither.
Last reviewed by the A2Z.Tools team against the sources listed above.
