Responsive Images That Actually Save Bandwidth: srcset, sizes, picture and Testing

A photo that looks sharp on a laptop can waste bandwidth on a small phone. A thumbnail that loads quickly on mobile may become blurry when displayed in a large desktop card. Responsive images solve both problems by giving the browser several useful versions of the same visual and enough information to choose among them.

The markup is simple once you separate three jobs: srcset lists candidates, sizes describes their expected display width, and <picture> lets you provide alternate formats or compositions. The hard part is checking that the browser downloads what you intended.

First decide whether the asset is content or decoration

A product photograph, article illustration, or editorial image is usually content and belongs in an <img> element with meaningful alternative text when appropriate. An ornamental flourish can be CSS decoration. A small, repeated interface icon may be a candidate for an icon system or an image sprite sheet.

Web2Generators’ CSS sprite creator maps regions in an existing image sheet and generates background-position CSS; it does not combine unrelated pictures into one file. The related guide, CSS Sprites in Modern Web Design: When They Help and How to Test Them, explains why a sprite can suit small fixed-size icons but is not a substitute for responsive photography.

That distinction matters for accessibility, too. An <img> element offers native image semantics and an alt attribute. A CSS background image does not.

Step 1: Make the CSS layout responsive first

Before exporting a dozen variants, check how wide the image will appear. For a conventional content image:

.article-image {
  display: block;
  width: 100%;
  max-width: 100%;
  height: auto;
}

This makes the image fill its container without overflowing, but it does not tell the browser to download a smaller source. A 2400-pixel file can still be transferred to a phone and scaled down to 360 CSS pixels.

Measure the actual image slot, not only the viewport. A card inside a two-column layout might occupy half the viewport on desktop, even though the page itself is very wide. That is the key fact the browser needs in the next step.

For mock layouts, the Lorem Ipsum generator can fill cards with varied paragraphs and list lengths so you can test whether images stay aligned when real content grows.

Step 2: Use srcset with width descriptors

Prepare several versions of the same photograph, each with the same aspect ratio and crop. Then add them as candidates. The filenames below are illustrative; create the files at the stated widths before using this markup:

<img
  class="article-image"
  src="coast-720.jpg"
  srcset="
    coast-360.jpg 360w,
    coast-720.jpg 720w,
    coast-1200.jpg 1200w
  "
  sizes="(max-width: 700px) 100vw, 50vw"
  width="720"
  height="480"
  alt="Coastal path above a rocky shoreline"
>

The 360w, 720w, and 1200w descriptors report the intrinsic pixel width of each file. They are not breakpoints. Make sure they match the real file dimensions.

The sizes value describes the image’s expected CSS display width; it does not set that width. Your CSS layout must create the slots it describes. In this example, the image occupies roughly the viewport width on narrow screens and half the viewport width beyond 700 CSS pixels. If your card sits inside a max-width container, use a formula that reflects that container instead. 100vw everywhere often leads to unnecessarily large downloads on desktop grids.

The browser chooses a resource based on this information, device pixel ratio, zoom, browser behavior, and other constraints. You cannot force a specific candidate for every device, and you should not assume that a 360 CSS pixel slot always downloads a 360-pixel file. A device with 2x pixel density may choose a 720-pixel version.

This is different from an x density descriptor such as 1x, 2x, which can be helpful when a displayed asset has a fixed CSS size. For flexible page columns, width (w) candidates with sizes are usually easier to reason about.

Step 3: Use picture when the format or crop should change

<picture> supports two distinct use cases. Format switching offers newer encodings with a fallback. Art direction chooses a different crop for a narrow screen, for example a portrait subject instead of a wide landscape.

A format-fallback example:

<picture>
  <source type="image/avif" srcset="coast-360.avif 360w, coast-720.avif 720w, coast-1200.avif 1200w"
          sizes="(max-width: 700px) 100vw, 50vw">
  <source type="image/webp" srcset="coast-360.webp 360w, coast-720.webp 720w, coast-1200.webp 1200w"
          sizes="(max-width: 700px) 100vw, 50vw">
  <img class="article-image" src="coast-720.jpg"
       srcset="coast-360.jpg 360w, coast-720.jpg 720w, coast-1200.jpg 1200w"
       sizes="(max-width: 700px) 100vw, 50vw"
       width="720" height="480"
       alt="Coastal path above a rocky shoreline">
</picture>

The browser evaluates sources from top to bottom and uses the first compatible source whose conditions match. The <img> is essential: it supplies the fallback, alternative text, and image semantics. Each format still needs appropriately sized versions if you want both modern encoding and resolution selection. A selected source that returns an error is not a reliable way to trigger the JPEG fallback; verify every candidate URL.

Use <picture> with media conditions for a genuinely different crop. Do not use format switching as an excuse to resize art arbitrarily. If a mobile crop has a different aspect ratio, test its layout box carefully; the width and height attributes on <source> can help supported browsers reserve an appropriate ratio for art-directed sources.

Step 4: Reserve space to prevent layout shifts

Always provide truthful intrinsic dimensions on content images where possible. This enables the browser to compute an aspect ratio before the bytes arrive:

<img class="article-image" src="team-portrait.jpg" width="900" height="600"
     alt="Project team working around a table">

Combined with height: auto, the dimensions reserve space while allowing the rendered width to shrink. If you need a fixed-height card crop, use a container with a known aspect ratio and object-fit: cover, then verify that important subjects are not cut off at narrow widths.

Text and images interact. Test one-line and three-line headings, large accessibility font settings, translated labels, and an image that fails to load. Lorem Ipsum can stress-test spacing, but it cannot replace final editorial copy or descriptive alternative text.

Step 5: Decide what loads early and what waits

A hero image that is visible at page load can affect Largest Contentful Paint (LCP). Avoid setting loading="lazy" on your main above-the-fold visual. For a genuinely important hero, fetchpriority="high" can be useful, but overusing it competes with other critical resources.

Images far below the first viewport can often use native lazy loading:

<img class="article-image" src="detail-720.jpg" width="720" height="480"
     loading="lazy" decoding="async" alt="Detail of a wooden stair railing">

The exact lazy-load threshold is browser-dependent. A developer tool that shows an image waiting to load has not necessarily found an error; scroll the page, then observe when the request is triggered.

Be especially careful with CSS background hero images: they may be discovered later than an <img> in HTML. Use them when they are semantically decorative, not merely to avoid responsive-image markup. Google’s responsive image guidance  describes sizing, loading hints, and fetch priorities in more detail.

Step 6: Inspect what the browser really downloaded

Open DevTools, choose Network, disable restrictive filters, and reload with a cold-cache test when appropriate. Inspect the image requests and the actual resource sizes. Then try a narrow viewport, a wider viewport, and a high-density display or device emulation. Select the image element and inspect its currentSrc to identify the chosen URL; use Network to distinguish transferred bytes from cache reuse. Start a fresh load at each test size, since shrinking an already loaded page may keep the larger image.

Look for evidence, not assumptions:

For setup in Chrome, Firefox, Edge, and Safari, use How to Check Website Network Requests. When a new image appears stale after deployment, follow Why Your Website Serves Old Files: Debug Cache-Control and ETags with cURL to distinguish an incorrect reference from a cached response.

Step 7: Adopt new image formats without losing fallbacks

Formats evolve, and browser support differs by version. JPEG XL, for example, is supported in Firefox 158 according to its release notes , but that alone does not mean every visitor can decode image/jxl. Test the actual browser versions your audience uses and maintain a working fallback. The MDN image type guide  describes format characteristics and compatibility considerations; check release notes for recent changes.

A reliable rollout usually starts with a baseline JPEG or PNG, adds WebP or AVIF where they meaningfully help, and treats new formats as measured opportunities. Test both visual quality and file size on your actual photographs; a format label does not guarantee every image is smaller. Automated pipelines should verify that each transformed file is readable, has the advertised MIME type, and preserves the intended crop.

Our Firefox Enterprise news article explains why browser configurations also belong in a test plan. Check the versions and policies your visitors actually use instead of treating one successful test as universal support.

Images used in buttons or controls need additional attention. A decorative icon may have empty alt or be hidden from assistive technology, while an icon-only button still needs an accessible name. Use visible labels whenever space permits.

A practical responsive-image review before publishing

Choose a representative page with a hero, a card grid, and a smaller inline illustration. Record the final CSS slot sizes. Generate a few sensible candidate widths for each aspect ratio. Check that the code lists real intrinsic widths and that sizes matches the layout. Add explicit dimensions and useful alternative text. Verify that the hero is not lazy-loaded, and inspect downloads at several viewport sizes and pixel densities.

Most importantly, compare real performance before and after. Fewer bytes can help, but unnecessary variants, wrong crops, and late image discovery can undo the benefit. Responsive imagery should improve the page without making content harder to understand.

If you’re also refining a group of small interface icons, the Web2Generators CSS sprite creator is a practical companion for mapping an existing icon sheet after the larger content images are working correctly.