Responsive Images and srcset: A Beginner’s Guide

Serving the same full-size image to a phone screen and a 4K desktop monitor is one of the most common, and most fixable, sources of wasted bandwidth on the web. The srcset attribute solves this — letting the browser pick the right-sized image for each visitor’s actual screen, automatically.

Responsive Images and srcset

The Problem Responsive Images Solve

A single <img> tag traditionally points to one file:

<img src="photo-large.jpg" alt="Description">

If photo-large.jpg is sized for a large desktop display, every visitor downloads that same large file — including someone on a phone, where the image displays at a fraction of the size and most of that downloaded data is simply wasted, never actually rendered at full resolution.

How srcset Works

srcset lets you offer the browser several versions of the same image at different resolutions (see MDN’s guide to responsive images for the full technical reference), along with a description of your layout, and the browser picks the most appropriate one for that specific visitor’s screen:

<img
  src="photo-800.jpg"
  srcset="photo-400.jpg 400w, photo-800.jpg 800w, photo-1200.jpg 1200w"
  sizes="(max-width: 600px) 100vw, 800px"
  alt="Description">

Breaking this down:

• srcset lists each available version with its actual pixel width (400w means that file is 400 pixels wide)
• sizes tells the browser how large the image will actually display at different viewport widths — in this example, full-width on screens under 600px, and a fixed 800px otherwise
• src remains as a fallback for browsers that don’t support srcset at all (extremely rare today, but harmless to include)

The browser combines its own screen size, pixel density, and the sizes hint to calculate which file in srcset best fits, then downloads only that one — not all of them.

Responsive Images and Srcset Example

Here is a concrete example:

Say you have a blog featured image that displays at a maximum of 1200px wide on desktop, but full-width (which might only be 380px) on a typical phone. Without srcset, every visitor downloads the full 1200px version. With it:

<img
  src="hero-1200.jpg"
  srcset="hero-400.jpg 400w, hero-800.jpg 800w, hero-1200.jpg 1200w"
  sizes="(max-width: 480px) 100vw, (max-width: 1024px) 90vw, 1200px"
  alt="Blog post hero image">

A phone visitor downloads the ~400px version — a fraction of the file size — while a desktop visitor still gets the full 1200px version. Same markup, right-sized image for everyone.

The Simplest Approach: CSS-Only Responsive Images

Before reaching for srcset, it’s worth knowing the simplest technique of all — a single CSS rule:

img {
  max-width: 100%;
  height: auto;
}

This makes any image shrink to fit its container on smaller screens, and it’s genuinely enough for a lot of simple sites. What it doesn’t do is reduce the actual file downloaded — a phone visitor still downloads the full-size image, just displayed smaller. This is exactly the gap srcset closes: CSS controls display size, srcset controls which file actually downloads. Frameworks like Bootstrap bundle this same CSS behavior into a class (.img-fluid), which is why it may look familiar if you’ve used one.

The <picture> Element: A Different Kind of Responsive Image

srcset on an <img> tag solves one problem: serving the same image at different resolutions. The <picture> element solves a different, related problem: serving genuinely different images — or different formats — depending on the situation.

Format-switching (the most common use):

<picture>
  <source srcset="photo.avif" type="image/avif">
  <source srcset="photo.webp" type="image/webp">
  <img src="photo.jpg" alt="Description">
</picture>

The browser picks the first format it supports, from top to bottom, falling back to the plain <img> if nothing else matches. This is how you can offer AVIF and WebP to browsers that support them while still guaranteeing a JPG fallback for anything that doesn’t.

Art direction (a genuinely different image per screen size, not just a resized one):

<picture>
  <source media="(max-width: 600px)" srcset="photo-cropped-square.jpg">
  <img src="photo-wide.jpg" alt="Description">
</picture>

This is different from srcset‘s resolution-switching — here, the phone version isn’t just a smaller copy of the same image, it’s a differently cropped one (say, a tight square crop instead of a wide landscape shot), because what looks right at a wide desktop size doesn’t always look right on a narrow phone screen.

Rule of thumb: use srcset on a plain <img> when you just need different sizes of the same image. Reach for <picture> when you need different formats, or an actually different crop/composition per screen size.

Do You Need to Set This Up Manually?

Usually not, if you’re on WordPress. Since WordPress 4.4, srcset and sizes are generated automatically for any image uploaded through the Media Library, based on the image sizes WordPress creates on upload (thumbnail, medium, large, and full, plus any additional sizes your theme registers). This is genuinely one of those cases where the platform handles a fairly technical optimization for you by default.

Where manual srcset still matters:

• Custom-coded sections outside the standard content editor (a custom homepage template, for instance)
• Background images set via CSS, which srcset doesn’t apply to at all — those need a separate technique (image-set() in CSS, though support and behavior varies)
• If you’re hand-coding a static site or web app without WordPress handling it for you

Checking Whether It’s Actually Working

1. View a page’s source (or Inspect an image element)
2. Look for a srcset attribute on the <img> tag — if it’s present with multiple file references, responsive images are active
3. To confirm the browser is actually using it correctly, open Chrome DevTools → Network tab, throttle to a mobile viewport size, and reload — you should see a smaller file requested than what a desktop viewport would trigger

If your WordPress images have no srcset at all, something may be interfering — a page builder that hand-codes <img> tags without preserving it, or a caching/optimization plugin misconfigured to strip attributes it shouldn’t.

Frequently Asked Questions

Whatever base image you upload, make sure it starts properly compressed — free and instantly, with our browser-based tool — since every size WordPress generates from it inherits the same compression quality as the original.

Related Posts

• Core Web Vitals and Images: What You Need to Know
• How Image Size Affects Google PageSpeed Score
• Lazy Loading Images: What It Is and How to Enable It