What is Responsive Images?

Why shrinking with CSS is not enough

Squeeze a 2400-pixel photo into a 375-pixel phone screen with CSS and it looks fine, yet the browser still downloads every byte of the large file. Swapping the source with JavaScript after measuring the viewport does not help either: the browser's preload scanner starts fetching images from the HTML before CSS and scripts have been processed. The candidates therefore have to be declared in the HTML, where the browser looks first.

Resolution switching with srcset and sizes

<img
  src="/img/team-800.jpg"
  srcset="/img/team-480.jpg 480w,
          /img/team-800.jpg 800w,
          /img/team-1200.jpg 1200w,
          /img/team-1600.jpg 1600w"
  sizes="(max-width: 700px) 100vw, 640px"
  width="1600" height="900"
  alt="Project team in a meeting at the office">

• Values such as 480w in srcset state each file's real pixel width, so the browser knows the candidates' sizes without downloading them.
• sizes describes the width the image will occupy in the layout: “full viewport width below 700 pixels, otherwise 640 pixels”. The first matching condition wins.
• The browser multiplies that slot width by the device pixel ratio. On a 390-pixel-wide phone with a 3× screen it needs 1170 pixels and picks the 1200w file; on a 1× desktop the 640-pixel slot is covered by the 800w file.

The specification deliberately leaves the final decision to the browser: it may reuse a larger version already in its cache or choose a smaller one when the user has asked to save data. The plain src remains the fallback for clients and tools that do not understand srcset.

Fixed-size images and x descriptors

If a logo is always displayed at 160 pixels, a width list is overkill; density switching is enough: srcset="/img/logo-160.png 1x, /img/logo-320.png 2x". This pattern is only correct when the rendered size is fixed. In fluid layouts, use w descriptors with sizes. For vector logos, a single SVG avoids the problem entirely.

Art direction with picture

Sometimes the problem is composition rather than file size. A wide hero shot that works on desktop turns into a thin strip on a phone, with the people in it reduced to specks. The picture element lets you supply a differently cropped image per condition:

<picture>
  <source media="(max-width: 699px)"
          srcset="/img/hero-portrait-600.jpg 600w, /img/hero-portrait-900.jpg 900w"
          sizes="100vw">
  <img src="/img/hero-1600.jpg"
       srcset="/img/hero-1200.jpg 1200w, /img/hero-1600.jpg 1600w"
       sizes="100vw" width="1600" height="700"
       alt="Sunset over the harbour" fetchpriority="high">
</picture>

The browser uses the first source whose media condition matches and falls back to the img otherwise. The same structure, with a type attribute, handles format selection, as shown in the WebP entry. Alt text, dimensions and loading hints always belong on the img.

Mistakes that cost LCP and CLS

• Leaving out sizes: with w descriptors and no sizes, the browser assumes the image spans the full viewport and fetches a file far too large for a narrow column.
• A sizes value that no longer matches the CSS: when a redesign shrinks the image slot and nobody updates sizes, the savings quietly disappear. For lazy-loaded images, sizes="auto" lets the browser use the actual laid-out width, though browser support is still uneven.
• Missing width and height: they give the browser the aspect ratio up front and prevent the jumps that add to CLS.
• Lazy-loading the hero: loading="lazy" on the first visible image delays LCP; lazy loading is meant for images below the fold.
• Dropping the fallback src: Google recommends always providing one, since some browsers and crawlers may not understand these attributes. For how images are found in search, see image SEO.