Related: What loading="lazy" Does and Why Google Added It to the HTML Spec covers the other half of image loading behavior that pairs with responsive image selection.

A user on a 375px iPhone with a 3x retina display viewing your site on 4G should get a different image file than a user on a 1440px desktop with a 1x monitor on a slow hotel WiFi connection. These two users have completely different needs: one wants a sharp image at a small size, the other wants a smaller file at a large size. Without srcset and sizes, they both get the same file, and at least one of them is getting it wrong.

What this covers: Why a single image URL cannot serve all devices correctly, what the srcset and sizes attributes actually tell the browser, how the browser's selection algorithm works, and the common mistakes that make the whole system silently fail.

The problem with a single image URL

When you write <img src="/hero.jpg">, every visitor to your page downloads the same file regardless of their device, screen size, or connection speed.

For a full-bleed hero image that looks good on a 4K monitor, you might need a 2400px wide image. On a 375px phone, that same image takes four times more bandwidth to download than needed. The phone then scales it down to 375px, discarding all that extra data. You paid for data that was thrown away.

The inverse is also a problem. If you serve a small image to save bandwidth, it looks blurry on high-density displays like Retina screens because those screens pack 2x or 3x more pixels into the same physical space and need a proportionally larger image to fill them sharply.

<!-- Every device gets the same 2400px image. Wrong. -->
![Hero image](https://renderlog.in/hero-2400.jpg)

The solution is not to pick one compromise image. The solution is to tell the browser about all your image options and let it pick the right one based on information it already has: the viewport size, the device pixel ratio, and the connection speed.

What srcset actually tells the browser

The srcset attribute is a comma-separated list of image candidates. Each candidate has a URL and a width descriptor that tells the browser how wide that image file is in pixels.

![Hero image](https://renderlog.in/hero-800.webp)

The w unit after each number is the intrinsic width of that image file. It is not the display width. It is saying: "this file, when you open it, is 800 pixels wide." That is a fact about the file, not an instruction to the browser.

The src attribute is the fallback for browsers that do not understand srcset. Old browsers ignore srcset and use src instead. Always include it.

Without a sizes attribute, the browser assumes the image will be displayed at 100% of the viewport width. That assumption is wrong for almost every real layout, which is why sizes exists.

What sizes tells the browser

sizes tells the browser how wide the image will actually appear on screen at different viewport sizes. It uses the same media query syntax as CSS.

![Hero image](https://renderlog.in/hero-800.webp)

Reading the sizes value here: if the viewport is 768px or narrower, the image takes up 100% of the viewport width. If the viewport is between 768px and 1200px, the image takes up 50% of the viewport width. Otherwise, the image is exactly 1200px wide (capped by a max-width container).

The browser reads sizes before it has applied any CSS. This is intentional. The browser preloader runs very early in the parsing process, before stylesheets are downloaded, to get image requests into the network queue as soon as possible. It cannot wait for CSS to be parsed to know image display sizes. So you, the developer, tell it the answer ahead of time through sizes.

The selection algorithm

Given srcset and sizes, the browser calculates which image to fetch like this:

1. Evaluate the sizes conditions against the current viewport width to get the rendered width (call it W)
2. Multiply W by the device pixel ratio (DPR) to get the needed pixels (call it P)
3. Pick the smallest image from srcset that is at least P pixels wide

For a concrete example: viewport is 375px wide, DPR is 3x, sizes says 100vw at this breakpoint.

• Rendered width W = 375px
• Needed pixels P = 375 x 3 = 1125px
• Available candidates: 400w, 800w, 1200w, 2400w
• Smallest that is at least 1125px wide: 1200w
• Browser fetches /hero-1200.webp

Without srcset and sizes, that same device would fetch /hero-2400.webp, downloading 4x more data than it needs to render a sharp image.

On a 1440px desktop with 1x DPR where the image appears at 50% viewport width:

• Rendered width W = 720px
• Needed pixels P = 720 x 1 = 720px
• Smallest candidate at least 720px: 800w
• Browser fetches /hero-800.webp

A desktop user on a 1x monitor is downloading a smaller file than an iPhone user, because the desktop user does not need the extra pixels that a retina display requires.

The picture element for format switching

srcset on a plain <img> handles size selection but not format selection. For that, you use the <picture> element, which lets you offer different formats with explicit priority order.

<picture>
  <source
    type="image/avif"
    srcset="
      /hero-400.avif   400w,
      /hero-800.avif   800w,
      /hero-1200.avif 1200w
    "
    sizes="(max-width: 768px) 100vw, 1200px"
  />
  <source
    type="image/webp"
    srcset="
      /hero-400.webp   400w,
      /hero-800.webp   800w,
      /hero-1200.webp 1200w
    "
    sizes="(max-width: 768px) 100vw, 1200px"
  />
  ![Hero image](https://renderlog.in/hero-1200.jpg)
</picture>

The browser works through <source> elements in order, picks the first one it supports, and applies the same size selection algorithm from srcset. A browser that supports AVIF gets AVIF at the right size. A browser that does not falls through to WebP. If neither is supported, the <img> fallback loads the JPEG.

Common mistakes that make this silently fail

Using pixel density descriptors instead of width descriptors. There is a second descriptor syntax that uses x instead of w, like srcset="/hero-2x.jpg 2x". This only handles DPR, not viewport size. It is the older syntax and far less flexible. Use w descriptors with sizes instead.

<!-- Older approach: only handles DPR, ignores viewport size -->
![Hero](https://renderlog.in/hero.jpg)

<!-- Better: handles both DPR and viewport size -->
![Hero](https://renderlog.in/hero-800.jpg)

Wrong sizes values. If your sizes attribute says 100vw but the image is actually displayed at 50% of the viewport inside a two-column layout, the browser will fetch a file twice as large as needed. Get the rendered width right, even if it means inspecting the layout in DevTools to measure the actual computed width at each breakpoint.

Skipping sizes entirely. Without sizes, the browser assumes the image is 100vw. On a 1440px desktop with a two-column layout where your image is actually 600px wide, the browser fetches a 1440px image. The default assumption is almost always too large for content images.

Not including the image dimensions. Without width and height on the <img> element, the browser cannot reserve space for the image before it loads. When the image arrives, the page reflows and you get Cumulative Layout Shift. This applies whether you use srcset or not, but it is especially visible with lazy-loaded responsive images because the load is intentionally deferred.

What about CSS background images?

srcset and sizes only work on <img> elements and <source> elements inside <picture>. CSS background images do not benefit from this system at all.

For responsive CSS background images, the only native option is image-set():

.hero {
  background-image: image-set(
    url('/hero-800.webp') 1x,
    url('/hero-1600.webp') 2x
  );
}

image-set() is less flexible than srcset because it only handles DPR, not viewport size. For hero sections or any prominent image, using an <img> element with proper srcset and sizes is almost always the better choice over a CSS background image.

Generating responsive images in practice

Manually creating and maintaining multiple resized versions of every image is not practical at scale. The standard approach is to generate them automatically:

Vite and Astro both have image optimization plugins that generate multiple sizes at build time from a single source image. Astro's <Image> component handles srcset generation automatically when you specify a widths prop.

Next.js provides an <Image> component that generates srcset and handles format selection automatically, including on-demand resizing through its image optimization API.

CDN image optimization services like Cloudinary, Imgix, and Cloudflare Images let you request any size via URL parameters and serve the optimal format based on the Accept header. You store one original image, the CDN handles the rest.

The common thread is that the developer should not be manually maintaining five versions of every image. The build tool or CDN should generate them. What the developer needs to understand is srcset and sizes so they know what the tool is doing and can write the right configuration.

The performance case in numbers

The only device in this table that should download the full 2400px image is the 4K display with a 2x DPR where the image fills the viewport. Every other device is paying for data that gets discarded after the browser scales the image down. srcset and sizes stop that from happening.

Read the original article on Renderlog.in:
https://renderlog.in/blog/srcset-sizes-responsive-images-explained/

If you found this helpful, I've also built some free tools for developers and everyday users. Feel free to try them once:

JSON Tools: https://json.renderlog.in
Text Tools: https://text.renderlog.in
QR Tools: https://qr.renderlog.in