Dublin Library

The Publishing Project

Simplifying Responsive Images

  • 16 min. read

 

Responsive images have significantly improved web performance by saving users from downloading unnecessary bytes. However, implementing them effectively has long been a source of frustration for developers. The new sizes="auto" feature changes the way you write image markup, significantly reducing developer overhead.

This article explores the evolution of responsive images, explains the mechanics of srcset and <picture>, and details how sizes="auto" simplifies the process.

The evolution of responsive images #

Before responsive image standards existed, developers used a single src attribute. This forced all users—regardless of device size or network connection—to download a single, often enormous, image file. As mobile web usage surged, the need for responsive solutions became critical.

To solve this, two distinct syntaxes emerged: <picture> and the combination of srcset and sizes.

The prescriptive approach: <picture> #

The <picture> element offers explicit control. You prescribe exactly which image source the browser must use under specific conditions (using media queries).

<picture>
  <source media="(min-width: 800px)" srcset="hero-large.jpg">
  <source media="(min-width: 400px)" srcset="hero-medium.jpg">
  <img src="hero-small.jpg" alt="A descriptive alt text">
</picture>

Note that the browser evaluates <source> elements from top to bottom and uses the first source whose media query matches. In this example, on a viewport wider than 800px, the first source wins; the second source acts as a fallback for viewports between 400px and 800px.

Because the media attribute accepts any standard CSS media query, you can also use modern range media queries. This makes your markup significantly cleaner when targeting strict viewport brackets, as you no longer need to chain min-width and max-width together:

<picture>
  <source media="(width >= 1024px)"
            srcset="hero-desktop.jpg">
  <source media="(400px <= width < 1024px)"
            srcset="hero-tablet.jpg">
  <img 	src="hero-mobile.jpg"
        alt="A descriptive alt text">
</picture>

This prescriptive syntax works exceptionally well for art direction—such as cropping an image differently for mobile layouts. Note that a standard <img> tag cannot accept multiple srcset attributes. Therefore, if you want to provide modern image formats like AVIF or WebP while ensuring reliable fallbacks for older browsers, using the <picture> element is strictly required.

However, if you only need simple resolution switching for a single format, using <picture> can become a massive headache. Attempting to manually calculate media queries for every possible combination of viewport widths and 1x, 2x, or 3x device pixel densities results in bloated, brittle markup. It shifts the entire burden of logic unnecessarily onto you, the developer.

Worse, it strips the browser of its autonomy. Because media queries are rigid commands, the browser must obey them blindly. It has less room to factor in OS-level 'Save Data' preferences or cache reuse heuristics. For example, if the browser has already downloaded a large desktop image and the user resizes their window down, a <picture> media query can trigger an additional download for a smaller mobile candidate. To solve this, we need an approach that gives the browser its brain back.

The descriptive approach: srcset and sizes #

When you only need the browser to download an appropriately sized image without changing the crop or the format, you use a descriptive syntax. Instead of giving the browser strict orders via media queries, you provide a menu of available files.

<img src="fallback.jpg"
  srcset="	small.jpg 300w,
            medium.jpg 600w,
            large.jpg 1200w"
  sizes="(min-width: 1024px) 800px,
        calc(100vw - 2rem)"
  alt="A descriptive alt text">

In this setup:

  • srcset lists the candidate images and their intrinsic widths.
  • sizes tells the browser what the layout width of the image will be at various breakpoints.

This approach gives the browser its brain back. The browser evaluates the screen density, viewport size, and connection speed, checks the sizes attribute to see how large the image will render, and autonomously selects the most efficient file from the srcset.

Understanding the w descriptor #

To make the descriptive approach work, the browser needs to know the size of each file before it downloads it. This is where the w descriptor comes in.

In the srcset attribute, you can use the w descriptor for width (e.g., 300w, 600w, 1200w), which represents the intrinsic width in physical pixels of that specific image file. Alternatively, the x descriptor (e.g., 1x, 2x, 3x) expresses device pixel ratio multipliers, useful when you have exact pixel-ratio variants rather than fluid size variants.

It is crucial to understand that 300w is not a CSS pixel (px) measurement. You are not telling the browser to render the image at 300 pixels. Instead, you are simply declaring a physical fact to the browser: "Hey, this small.jpg file happens to be exactly 300 actual pixels wide."

The browser looks at the sizes attribute to see how large the image will render on the screen, looks at the w descriptors to see what raw materials it has available, and calculates the best fit.

The illusion of exact control #

It is a common misconception that if you provide perfect sizes math, the browser will automatically pick the image that perfectly matches that dimension.

In reality, sizes is just a strong suggestion about the layout context. Browsers are completely free to choose whichever image they want from the srcset.

While the HTML specification allows browsers to consider network speed, in practice, modern browsers aggressively prioritize visual quality. On a high-density Retina screen, the browser will almost always choose an image double or triple the layout size to ensure it looks crisp, even on a slow connection. A browser will typically only choose an intentionally smaller, blurrier image to save bandwidth if the user has explicitly enabled an OS-level "Save Data" or "Low Data Mode".

Furthermore, srcset is cache-aware. If a user starts on a large desktop layout and resizes their browser down to a mobile view, the browser will often reuse the larger, higher-quality image it already has in cache and simply scale it down, avoiding an extra request. That flexibility is harder to preserve with strict media-query source switching in <picture>.

The old manual calculation feels exact, but it is ultimately just one variable the browser uses in its internal decision-making engine.

The problem with the sizes attribute #

While the descriptive approach offloads the download decision to the browser, it places a heavy authoring burden on developers through the sizes attribute.

Browsers parse HTML and discover image requests long before they download the CSS or calculate the page layout. Because the browser cannot measure the rendered layout at that stage, you must use sizes to predict the layout math.

Writing accurate sizes attributes is notoriously difficult. As layouts become complex with CSS grids, flexbox, and container queries, predicting the exact rendered width of an image across all breakpoints becomes nearly impossible without automated tooling. If you write inaccurate sizes attributes, you defeat the purpose of responsive images by serving files that are either unnecessarily large or unacceptably blurry.

Enter sizes="auto" #

The core issue with sizes stems from the timing of image requests. The browser needs the sizes attribute because it fetches images eagerly, before it knows the layout.

However, modern web development relies heavily on the loading="lazy" attribute, which defers loading off-screen images until the user scrolls near them. By the time a lazy-loaded image approaches the viewport, the browser has already downloaded the CSS and calculated the layout. The browser knows exactly how many pixels the image occupies.

This realization led to sizes="auto". When you use lazy loading, you can instruct the browser to calculate the sizes value automatically based on the actual rendered layout.

How sizes="auto" works #

To use the new feature, set the sizes attribute to auto. You must also include loading="lazy".

<img loading="lazy"
  sizes="auto"
  srcset="small.jpg 300w,
          medium.jpg 600w,
          large.jpg 1200w"
  src="fallback.jpg"
  alt="A descriptive alt text">

This single change eliminates the need for complex media queries and calc() functions in the sizes attribute. The browser simply measures the image element during layout and selects the optimal source from the srcset.

The width and height caveat (and the timing paradox) #

While sizes="auto" simplifies responsive images, it introduces a critical rendering constraint: it requires proper dimensions to prevent infinite layout cycles.

It can feel contradictory to use sizes="auto" to avoid hardcoding sizes, only to be required to hardcode HTML width and height attributes. To understand why, you must distinguish between three concepts:

  • Layout Size (The CSS problem): How wide is the image right now on the user's screen? (e.g., 345px on a phone). sizes="auto" completely solves this.
  • Intrinsic Size (The file's physical reality): What are the actual physical pixel dimensions of the source image file? (e.g., 1200 pixels wide by 800 pixels tall).
  • Intrinsic Aspect Ratio (The HTML problem): What is the inherent shape derived from that intrinsic size? (e.g., a 3:2 ratio).

If the browser doesn't know the Aspect Ratio of the image, it can't draw the empty box on the screen. If it can't draw the box, it can't calculate the layout. If it can't calculate the layout, sizes="auto" cannot work.

The timing paradox #

The browser can figure out the intrinsic size of the file on its own, but only after it downloads the file. Because sizes="auto" relies on lazy-loading, the browser waits for the layout to finish before it downloads the image. Because it hasn't downloaded the file, it is flying blind.

To break this loop, the HTML specification forces size containment on images using sizes="auto". In the browser's User Agent default stylesheet, these images receive rules equivalent to:

/* In the browser's default stylesheet */
img:is([sizes="auto" i], [sizes^="auto," i]) {
  contain: size !important;
  contain-intrinsic-size: 300px 150px;
}

If you rely on sizes="auto" without specifying dimensions, your image will collapse to a default 300x150 pixel box.

To resolve this dynamically without having to hardcode your own contain-intrinsic-size pixel values, you must provide the browser with the aspect ratio ahead of time. The standard practice is to supply the HTML width and height attributes matching the Intrinsic Size of the largest resource in your srcset.

HTML:

<!-- Use the Intrinsic Size of the largest image -->
<img loading="lazy"
  sizes="auto"
  width="1200"
  height="800"
  srcset="small.jpg 300w,
          medium.jpg 600w,
          large.jpg 1200w"
  src="fallback.jpg"
  alt="A descriptive alt text">

CSS:

img {
  width: 100%;
  height: auto;
  /*
    Modern browsers apply this automatically
    based on the HTML attributes, preventing
    the static 300x150 default trap dynamically
  */
  aspect-ratio: attr(width) / attr(height);
}

This combination gives the browser the raw intrinsic size ahead of time, allowing it to calculate the aspect ratio, draw the box, and execute sizes="auto" flawlessly.

Providing fallbacks #

Because sizes="auto" is relatively new, older browsers might not support it. Fortunately, you can provide a fallback syntax by appending standard sizes rules after the auto keyword.

<img loading="lazy"
  sizes="auto,
         (min-width: 1024px) 800px,
         100vw"
  width="1200"
  height="800"
  srcset="small.jpg 300w,
          medium.jpg 600w,
          large.jpg 1200w"
  src="fallback.jpg"
  alt="A descriptive alt text">

Browsers that support sizes="auto" will read the auto keyword, discard the rest of the string, and calculate the size automatically. Unsupported browsers will discard auto and fall back to evaluating the remaining breakpoints.

Combining prescriptive and descriptive approaches #

In complex layouts, you might need both art direction (changing the crop for different devices) and resolution switching (providing different file sizes for various display densities). You can combine both approaches by using <source> elements within a <picture> tag, where each <source> includes its own srcset and sizes attributes.

You can seamlessly integrate sizes="auto" into this combined setup. Apply sizes="auto" directly to the <source> elements and the fallback <img> element. Because the <img> element ultimately controls the loading behavior, you only need to declare loading="lazy" once on the <img> tag itself.

To ensure the browser allocates the correct layout space and prevents layout shifts, supply width and height attributes directly on the <source> tags to describe the specific aspect ratio of that crop.

<picture>
  <!-- Desktop crop: wide aspect ratio -->
  <source media="(min-width: 1024px)"
    width="1600"
    height="900"
    sizes="auto"
    srcset="hero-desktop-800.jpg 800w,
            hero-desktop-1600.jpg 1600w">

  <!-- Mobile crop: square aspect ratio -->
  <img loading="lazy"
    sizes="auto"
    width="800"
    height="800"
    src="hero-mobile-400.jpg"
    srcset="hero-mobile-400.jpg 400w,
            hero-mobile-800.jpg 800w"
    alt="A descriptive alt text">
</picture>

Important: The width and height on each <source> tag define the aspect ratio for that specific crop. The width and height on the fallback <img> tag define the aspect ratio when no media query matches. Each one reserves its own layout space based on its declared dimensions, so they can and should differ.

If you use aspect-ratio: attr(width) / attr(height) in your CSS, ensure it applies only to the active image element and does not conflict with <source> declarations. In mixed-ratio art-direction scenarios, remove the CSS aspect-ratio rule and let the HTML attributes handle ratio declaration per branch. This avoids forced scaling or layout conflicts.

This pattern gives you the prescriptive power of art direction, the descriptive efficiency of resolution switching, and the automated authoring convenience of sizes="auto".

Using responsive images with <figure> and <figcaption> #

You can seamlessly wrap responsive images—whether you use the standard <img> tag with srcset or the complete <picture> element—inside <figure> and <figcaption> elements. This approach is highly recommended for maintaining semantic HTML and improving accessibility when an image requires a visible caption.

Wrapping your image in a <figure> does not alter how sizes="auto" or srcset calculates the optimal file. The browser still waits for the CSS layout to finish, measures the rendered size of the <img> element within its <figure> container, and downloads the best source.

The only technical consideration involves CSS layout defaults. Browsers apply default block margins to <figure> elements in their User Agent stylesheets. If you do not account for these margins, your <figure> might not align with your grid, or it might force the image to render narrower than expected.

To ensure your responsive image scales fluidly and predictably, reset the <figure> margins and apply the standard fluid image CSS rules.

HTML:

<figure>
  <!-- The responsive image logic remains exactly the same -->
  <img loading="lazy"
    sizes="auto"
    width="1200"
    height="800"
    srcset="small.jpg 300w,
            medium.jpg 600w,
            large.jpg 1200w"
    src="fallback.jpg"
    alt="A descriptive alt text">
  <figcaption>The `sizes="auto"` logic works perfectly inside a figure element.</figcaption>
</figure>

CSS:

figure {
  /*
    Reset default browser margins
    to allow predictable fluid scaling
  */
  margin: 0;
  width: 100%;
}

figure img {
  width: 100%;
  height: auto;
  aspect-ratio: attr(width) / attr(height);
}

This ensures that the semantic grouping of the image and its caption does not interfere with the dynamic layout calculations required by sizes="auto".

The impact on responsive images #

The introduction of sizes="auto" drastically changes how developers author responsive images, though it does not completely eliminate manual sizes calculations.

  • Significant reduction in complexity: For the vast majority of images—those below the fold and suitable for lazy loading—you no longer need to write or generate complex layout predictions. You can rely on loading="lazy" and sizes="auto".
  • Accuracy improvements: Because the browser uses actual layout measurements rather than predicted CSS breakpoints, the selected image source will always be the most optimal choice for the user's specific context.
  • Exceptions for eager loading: Eagerly loaded images, such as Largest Contentful Paint (LCP) hero images at the top of the viewport, should not be lazy-loaded. Because these images trigger download requests before the CSS layout is calculated, you cannot use sizes="auto" for them. You must still write a standard sizes attribute that predicts the layout width, just as you did before sizes="auto" existed.

By combining explicit sizes for your most critical above-the-fold content and sizes="auto" for everything else, you can maintain optimal performance while significantly streamlining your codebase.

Verifying your responsive images #

Writing responsive image markup is only half the battle. You need a concrete way to verify that the browser is actually selecting the correct image from your srcset and respecting your layout calculations. Without validation, you might write perfect code and never know it's working—or assume it's broken when it is.

Inspect the Network tab #

Open your browser's DevTools and navigate to the Network tab. Load your page and locate the image requests. Click on each image to see:

  • Which candidate was selected from your srcset (the filename in the request URL).
  • The image dimensions in the response headers.
  • The response size to confirm the browser is not downloading unnecessarily large files.

Resize your browser window and watch the Network tab. If you trigger a new download, note the candidate that was chosen. This tells you whether sizes="auto" or your sizes attribute is guiding the browser correctly.

Emulate device pixel ratios #

Modern browsers have DevTools options to emulate different screen densities (1x, 2x, 3x). With sizes="auto" and lazy loading, this is especially important because the browser's density-aware selection happens after the layout is calculated.

In Chrome DevTools, press Ctrl+Shift+P (or Cmd+Shift+P on macOS), search for "Device Pixel Ratio," and select a multiplier. Reload the page and inspect which srcset candidate the browser downloads. On a simulated 2x screen, you should see larger candidates selected to maintain sharpness.

Test cache reuse with viewport resizing #

Start your page in a desktop viewport and note which image was downloaded. Then resize your browser window to a mobile viewport. If the browser is respecting cache-aware heuristics (especially relevant for srcset), the Network tab should show no new request for a smaller image—it will reuse and scale the already-cached larger image.

If you see a new request for a different candidate, the browser is being conservative about reusing cache, which is still correct behavior but less efficient. This helps you understand real-world performance trade-offs.

Enable Save Data mode #

Some browsers support a "Lite Mode" or "Save Data" preference that signals to servers and to the browser that bandwidth is constrained. In Chrome, enable this in Settings > Bandwidth (or via DevTools Network conditions). Reload your page and check if the browser selects a smaller candidate from your srcset.

On high-DPR screens, the browser might normally choose an image double the layout size. With Save Data enabled, it should scale back to closer to the actual layout width, saving bandwidth for users who have opted in.

These verification steps transform responsive images from a theoretical exercise to a measurable, observable reality. Once you confirm the browser is making the choices you expect, you can be confident in your implementation.

Understanding how to verify sizes="auto" also opens the door to thinking about responsive images at an architectural level—how they fit into modern design systems that embrace fluid layouts and component reusability.

Conclusion: the shift to intrinsic web design #

The sizes="auto" attribute and the philosophy of designing without breakpoints are two halves of the same shift in web development: moving from prescriptive developer control to intrinsic browser calculation. While designing without breakpoints gives up control over when layouts change, sizes="auto" gives up control over how image sizes are calculated. These concepts interlock to form a modern web architecture:

  • Intrinsic layouts make the sizes attribute impossible to write: In an intrinsic layout, such as grid-template-columns: repeat(auto-fit, minmax(8rem, 1fr)), there are no viewport breakpoints. A card scales up, drops in width when the browser has enough room to spawn a new column, and then starts scaling up again. Because sizes="auto" waits for the CSS Grid calculation to finish before fetching the image, it is the only way to serve correctly sized images in an auto-fit or auto-fill grid without reverse-engineering complex browser math.
  • True component portability: Container queries allow a component to adapt its CSS using @container without knowing where it is placed. Traditional sizes ruins that portability by tying the image to the viewport. Pairing container queries with sizes="auto" achieves complete component portability. The CSS layout adapts based on the container width, and the image dynamically downloads the correct file size based on that newly adapted layout.
  • Fluidity from typography to network: Intrinsic design uses tools like clamp() to scale typography and spacing smoothly. The sizes="auto" attribute applies this fluid mindset to network requests. Instead of jumping from a small file to a massive file at an arbitrary viewport threshold, sizes="auto" allows the browser to smoothly step up the srcset ladder, grabbing the most efficient file for the exact fluid width the image occupies.

Stop trying to micromanage the browser. Give it a fluid grid, a list of image files, and let the native rendering engine do the math.

References #

Edit on Github