Responsive Images srcset: The Complete Guide for Developers

The Responsive Image Problem: Why One Size Hurts Everyone

Here's a scenario every web developer has encountered. You build a beautiful hero banner at 2400 pixels wide — it looks stunning on your 27-inch monitor. Then you check your site on a phone: the same 2400px image loads over a 4G connection, burning through 2MB of data to display in a 375px-wide container. The user sees zero quality benefit, but they pay the full bandwidth cost.

This isn't just a mobile annoyance — it's a measurable problem. The HTTP Archive's 2025 Web Almanac found that 62% of desktop image bytes are wasted on mobile viewports because sites serve desktop-sized images to all devices indiscriminately. That's megabytes of unnecessary data on every single page view. Multiply that across millions of visitors, and you're looking at real-world consequences: higher bounce rates on slow connections, inflated CDN bills, and lower Core Web Vitals scores that directly affect search rankings.

The solution isn't to serve smaller images everywhere — desktop users on retina displays need those 2400px images. The solution is to serve the right image for each device, and that's exactly what the srcset attribute does.

srcset Syntax: Width Descriptors, Density Descriptors, and sizes

The srcset attribute lets you provide multiple versions of an image and let the browser pick the best one. There are two flavors: width descriptors (the modern standard) and pixel density descriptors (the legacy approach). Understanding both is essential because you'll encounter each in real codebases.

Width Descriptors (w) — The Right Way

Width descriptors tell the browser the actual pixel width of each image candidate. Paired with the sizes attribute, the browser calculates which image to download before the page layout is even complete:

<img
  src="hero-800w.jpg"
  srcset="hero-400w.jpg 400w,
          hero-800w.jpg 800w,
          hero-1200w.jpg 1200w,
          hero-2400w.jpg 2400w"
  sizes="(max-width: 600px) 100vw,
         (max-width: 1200px) 50vw,
         33vw"
  alt="Product hero image"
  width="2400"
  height="1600">

Here's what happens step by step. The browser reads sizes and determines how wide the image slot will be — on a 375px phone, that's 100vw (375px). It then picks the smallest image in srcset that's at least 375px wide — in this case, the 400w version. On a 1440px desktop where the image occupies 33vw (475px), the browser reaches for the 800w candidate. The src attribute serves as a fallback for browsers that don't understand srcset, which in 2026 means essentially none — but it's still good practice to include it.

The magic of this approach is that it works before CSS and JavaScript execute. The browser calculates the sizes from media conditions alone, meaning it can start downloading the right image immediately — no layout thrashing, no JavaScript dependency, and no wasted bandwidth.

Pixel Density Descriptors (x) — The Legacy Approach

Before width descriptors became widespread, developers used pixel density descriptors to serve higher-resolution images to retina displays:

<img
  src="photo-1x.jpg"
  srcset="photo-1x.jpg 1x,
          photo-2x.jpg 2x,
          photo-3x.jpg 3x"
  alt="Product photo">

The 1x, 2x, and 3x values refer to device-pixel-ratio (DPR). A standard display gets the 1x image; a 2x retina display gets the sharper 2x version. This approach is simpler but has a fundamental flaw: it doesn't account for image display size. A 2x image served to a retina phone may still be far larger than necessary if the image only occupies a quarter of the screen width. For that reason, width descriptors have largely replaced density descriptors in modern development — but you'll still find density descriptors in older codebases and simpler implementations.

Making srcset Work in Production: Patterns That Ship

Understanding the syntax is step one. Applying it effectively requires solving the practical problems every production site faces: how many image variants to generate, which breakpoints to target, and how to avoid maintaining 20 versions of every photo.

The Three-Breakpoint Rule

A common mistake is generating too many variants — 10 or 12 per image — which creates a maintenance burden without meaningful performance gains. In practice, three image widths cover 90% of use cases: 400w for mobile, 800w for tablet, and 1600w for desktop. If your design has a critical hero image that spans the full viewport, add a 2400w variant for large retina displays. For thumbnails and in-content images that never exceed 600px, two variants (400w and 800w) are sufficient.

Before generating these variants, compress your source images first. Use Image Toolbox Compress to batch-reduce file sizes — a well-compressed 1600px image can weigh under 100KB, making even your largest variant lightweight. Combine this with modern formats: serving WebP or AVIF with srcset delivers maximum compression alongside responsive delivery. You can convert to WebP or AVIF directly in the browser, no server-side processing required for smaller projects.

Automating Responsive Image Code

Writing correct srcset and sizes attributes for every image on a page is tedious and error-prone. The sizes attribute in particular requires knowing exactly how wide each image renders at every breakpoint — information that lives in your CSS, not your HTML. This is where tooling makes a difference. Use the Image Toolbox Web Optimizer to auto-generate responsive image code — it analyzes your image, generates the right srcset variants, calculates optimal sizes values based on your layout, and outputs ready-to-paste HTML with WebP/AVIF fallbacks in one step. This eliminates the manual trial-and-error that turns many developers away from responsive images entirely.

srcset + picture: When to Combine Them

The <picture> element and srcset are often confused, but they solve different problems. Use <picture> when you need art direction — showing a cropped or differently composed image on mobile vs desktop. Use srcset when you need resolution switching — the same image at different file sizes. In practice, you often combine them:

<picture>
  <source
    media="(max-width: 600px)"
    srcset="hero-cropped-400w.webp 400w,
            hero-cropped-800w.webp 800w"
    sizes="100vw"
    type="image/webp">
  <source
    srcset="hero-wide-800w.webp 800w,
            hero-wide-1600w.webp 1600w"
    sizes="(max-width: 1200px) 100vw, 66vw"
    type="image/webp">
  <img
    src="hero-fallback.jpg"
    alt="Hero banner"
    width="1600"
    height="900"
    loading="eager">
</picture>

This snippet demonstrates several best practices at once: art direction via <source media> (a mobile-optimized crop), resolution switching via srcset on each source, WebP format preference with JPG fallback in <img src>, and explicit width/height to prevent layout shift. The browser processes these conditions top-down, selecting the first matching <source> — if none match (or the browser doesn't support WebP), it falls through to the standard <img> element.

Frequently Asked Questions

References

• MDN: img srcset attribute — Mozilla's authoritative reference on srcset and sizes
• web.dev: Serve Responsive Images — Google's responsive image best practices guide
• MDN: The Picture element — Full documentation on art direction and format switching