Responsive Images: Multi-Size Generation for the Web

I once watched a client’s analytics and noticed that 62% of their traffic came from mobile devices. Fair enough — that’s been the norm for years. What wasn’t normal was their homepage hero image: a gorgeous 4000x2667 pixel photograph, weighing in at 3.4 MB, being dutifully downloaded by every single one of those mobile users. Users on phones with 375-pixel-wide screens. Phones that would display that image at roughly one-tenth of its native resolution, after wasting several seconds and a chunk of someone’s data plan downloading pixels they’d never see.

The image looked fantastic on a 27-inch monitor. On a phone over a spotty cellular connection? The user saw a white rectangle for four seconds, then a loading spinner, then maybe — if they hadn’t already bounced — the image finally appeared. Meanwhile, their LCP score was north of 6 seconds, and Google was quietly punishing them in search rankings for it.

This is the responsive images problem, and it’s one of the most widespread performance mistakes on the web. The fix isn’t complicated, but it does require generating multiple versions of every image and telling the browser which one to use. Let’s walk through all of it.

The Performance Tax Nobody Thinks About

Here’s a number that should make every developer uncomfortable: on the median webpage, images account for roughly half the total bytes transferred. Half. Not JavaScript. Not CSS. Not fonts. Images.

And the dirty secret is that a huge percentage of those bytes are completely wasted. A study by HTTP Archive found that the average webpage serves images that are, on average, significantly larger than their display dimensions require. We’re talking about 1600-pixel-wide images crammed into 400-pixel containers. Four times the pixels. Four times the bytes. Four times the download time. All for zero visual benefit.

On a desktop broadband connection, you might get away with this. A 500 KB image that could’ve been 120 KB loads in 200 milliseconds either way, and nobody notices. But on mobile — where more than half your traffic probably lives — those extra bytes add up brutally. A 4G connection averaging 15 Mbps turns a 500 KB image into a roughly 270-millisecond download. Scale that across 15 images on a page, and you’ve burned several seconds of load time on pixels the user will literally never see.

And then there’s LCP. Google’s Largest Contentful Paint metric measures when the biggest visible element renders, and on 70%+ of web pages, that element is an image. If your hero image is oversized and unoptimized, your LCP is bad, your Core Web Vitals are bad, and your search rankings suffer. For a deep dive on how images impact every Core Web Vital, check out our image compression and page speed guide.

The bottom line: serving a single image size to every device is a performance tax. You’re paying it in slower load times, worse user experience, higher bounce rates, and lower search rankings. And the wild part is how straightforward it is to stop paying it.

What “Responsive Images” Actually Means

The phrase gets thrown around a lot, but let’s be precise about what we’re talking about. Responsive images means serving different image files to different devices based on their screen size, pixel density, or both. The browser picks the most appropriate version, downloads only that one, and ignores the rest. (This is a different problem from needing different sizes for different platforms — if you’re resizing for social media, our social media image sizes guide covers that.)

HTML gives you two mechanisms for this: the srcset attribute and the <picture> element. They solve slightly different problems.

srcset and sizes: Resolution Switching

The srcset attribute lets you provide a list of the same image at different sizes. The browser looks at the viewport width, the pixel density of the screen, and the sizes attribute you’ve provided, then picks the best match.

<img src="product-800.webp"
     srcset="product-400.webp 400w,
             product-800.webp 800w,
             product-1200.webp 1200w,
             product-1600.webp 1600w,
             product-2000.webp 2000w"
     sizes="(max-width: 600px) 100vw,
            (max-width: 1200px) 50vw,
            800px"
     alt="Product photograph"
     width="1600"
     height="1200"
     loading="lazy">

The sizes attribute tells the browser: “On screens up to 600px wide, this image takes up 100% of the viewport width. On screens up to 1200px wide, it takes up 50%. Beyond that, it’s displayed at 800px.” The browser uses that information plus the device pixel ratio to calculate which file to download.

On a phone with a 375px viewport and a 2x display, the browser calculates: 375px viewport times 100vw times 2x pixel ratio equals 750px needed. It’ll grab the 800w version. On a desktop at 1400px with a 1x display, it calculates 50vw is 700px, so it grabs the 800w version there too. Same result, totally different reasoning.

The src attribute serves as a fallback for ancient browsers that don’t understand srcset. Those browsers just download the 800px version, which is a reasonable middle ground.

The picture Element: Art Direction

Sometimes you don’t just need the same image at different sizes — you need a completely different crop. A wide landscape banner that works on desktop might not work at all on mobile because the subject gets too tiny. You need a tighter crop for narrow screens.

That’s what the <picture> element handles:

<picture>
  <source media="(max-width: 600px)"
          srcset="hero-mobile.webp"
          type="image/webp">
  <source media="(max-width: 1000px)"
          srcset="hero-tablet.webp"
          type="image/webp">
  <source srcset="hero-desktop.webp"
          type="image/webp">
  <img src="hero-desktop.jpg"
       alt="Hero banner"
       width="1600"
       height="600">
</picture>

The browser evaluates the <source> elements top-to-bottom and uses the first one whose media query matches. If none match (or if the browser doesn’t support <picture>), it falls back to the <img> tag.

For an overview of which file formats play best with these techniques, our image file formats for the web guide covers the tradeoffs.

The Breakpoints That Actually Matter

I’ve seen people generate 12 different sizes of every image, trying to cover every possible viewport. That’s overkill. You’re adding build complexity and storage costs for marginal bandwidth savings. On the other end, I’ve seen sites that generate exactly two sizes — “mobile” and “desktop” — which leaves huge gaps where the browser is still downloading way more than it needs.

Five sizes hits the sweet spot for most use cases. (If you need a broader reference for platform-specific dimensions beyond responsive breakpoints, our image dimensions reference has every size in one place.)

400px — Covers small phone screens at 1x density. On a 2x phone (which is basically all of them now), this handles viewports up to about 200 CSS pixels wide. You won’t use this one much as a primary display size, but it’s essential for thumbnail grids and sidebar images on mobile.

800px — The workhorse mobile size. A 375px phone at 2x needs a 750px image; an 800px version covers that perfectly. This is your most-downloaded size on phone traffic.

1200px — Covers tablets at 1x, larger phones at 3x, and smaller laptop screens. It’s also a solid default for blog content images displayed at typical column widths.

1600px — Laptops and standard desktop monitors. Good for hero images and full-width content on 1x displays.

2000px — Large monitors and retina laptops. A 13-inch MacBook Pro with a 2x display showing a full-width image needs about 2560 pixels, so 2000px gets close. For most content images (which aren’t full-width), 2000px is more than enough.

Here’s what the srcset looks like in practice:

<img src="photo-1200.webp"
     srcset="photo-400.webp 400w,
             photo-800.webp 800w,
             photo-1200.webp 1200w,
             photo-1600.webp 1600w,
             photo-2000.webp 2000w"
     sizes="(max-width: 600px) 100vw,
            (max-width: 1200px) 80vw,
            1200px"
     alt="Descriptive alt text"
     width="2000"
     height="1333">

That sizes attribute is doing real work. It tells the browser the image will be full-viewport on phones, 80% of the viewport on tablets and small desktops, and capped at 1200px on large screens. Without sizes, the browser assumes the image is 100vw at all viewports, which leads to it downloading oversized files on desktop (where the image is probably contained in a narrower column).

Art Direction vs. Resolution Switching: When You Need Both

This is a distinction that trips up a lot of developers. Resolution switching and art direction solve fundamentally different problems, and conflating them leads to either broken layouts or wasted effort.

Resolution switching is simple: same image, different file sizes. The photo doesn’t change — it’s just bigger or smaller. A product shot at 400px wide looks like the same product shot at 2000px wide, just with fewer pixels. Use srcset with width descriptors (w) for this. It’s what you need 90% of the time.

Art direction is different: you’re serving genuinely different images (or different crops of the same image) at different viewport sizes. The classic example is a group photo used as a banner. On desktop, the wide crop shows eight people. On mobile, that same wide crop renders them as a row of unrecognizable tiny figures. You need a tighter crop — maybe focusing on just three people — to make the image work at small sizes.

You need art direction when the subject of the photo gets lost at small sizes, when the aspect ratio needs to change between breakpoints (landscape on desktop, square on mobile), or when text overlays on the image would become unreadable at certain widths.

For everything else — product photos, blog illustrations, thumbnails, background images — plain resolution switching with srcset is the right call. Don’t reach for <picture> when srcset will do the job. It’s more markup, more image variants to generate, and more complexity to maintain.

When you do need art-directed crops, BulkImagePro’s crop tool paired with the bulk resizer lets you create both the different crops and the different sizes you need across breakpoints.

Generating Multiple Sizes Without Losing Your Mind

Here’s where theory meets practice. You’ve got 50 product photos and you need each one at five sizes. That’s 250 images. Nobody is opening Photoshop and hitting “Save As” 250 times.

BulkImagePro’s bulk image resizer is built exactly for this workflow. Drop in your source images at their highest resolution, set your target widths, and export. The tool runs entirely in your browser — no uploads, no server processing, no waiting. Your images stay on your device the whole time.

Here’s the process I use for a typical responsive image set:

Start with the largest size you’ll need. If your source images are 4000px wide from the camera, great — that’s your master. If they’ve already been downsized, make sure your largest target width doesn’t exceed the source. Upscaling creates blurry images that are bigger files for worse quality — our guide to resizing without quality loss explains exactly why and how to avoid it. That’s the opposite of what we’re going for.

Batch resize to each breakpoint. I run through the set five times: once at 2000px wide, once at 1600px, once at 1200px, once at 800px, and once at 400px. With BulkImagePro, each pass takes maybe 15 seconds for 50 images. Naming them consistently is crucial — I use the pattern image-name-400.webp, image-name-800.webp, etc. When you’ve got 250 files, you need to be able to tell at a glance which variant is which.

Don’t forget the naming convention. Whatever pattern you pick, stick with it religiously. Your srcset markup depends on the filenames being predictable, and if you’re generating these images in a CMS pipeline or build step, the automation depends on it too.

For a comprehensive walkthrough of bulk resizing beyond responsive sets — batch resizing for social media, e-commerce, print, and more — our bulk image resizing guide covers the full picture.

WebP + Responsive: The Performance Double Punch

Responsive images and modern formats are two independent optimizations, but they compound beautifully. Serving a 400px WebP to a phone instead of a 2000px JPEG to the same phone isn’t a marginal improvement — it’s often a 90%+ reduction in file size.

Let me put real numbers on it. Take a typical product photo:

Variant	Format	Dimensions	File Size
Original	JPEG	2000x1333	680 KB
Resized	JPEG	400x267	52 KB
Resized	WebP	400x267	34 KB

That phone user goes from downloading 680 KB to downloading 34 KB. That’s a 95% reduction. Multiply it across 15 images on a product listing page, and you’ve saved the mobile user over 9 MB of data and shaved seconds off their load time.

The <picture> element makes it elegant to combine format selection with size selection:

<picture>
  <source type="image/webp"
          srcset="product-400.webp 400w,
                  product-800.webp 800w,
                  product-1200.webp 1200w,
                  product-1600.webp 1600w"
          sizes="(max-width: 600px) 100vw,
                 (max-width: 1200px) 50vw,
                 800px">
  <img src="product-800.jpg"
       srcset="product-400.jpg 400w,
               product-800.jpg 800w,
               product-1200.jpg 1200w,
               product-1600.jpg 1600w"
       sizes="(max-width: 600px) 100vw,
              (max-width: 1200px) 50vw,
              800px"
       alt="Product photo"
       width="1600"
       height="1200"
       loading="lazy">
</picture>

Browsers that support WebP (which is basically all of them in 2026 — we’re talking 97%+ global support) get the WebP files. The tiny sliver that don’t support it fall back to JPEG. Either way, the browser picks the right size for the device.

Converting your entire image set to WebP is simple. After you’ve generated your responsive sizes with the bulk resizer, run each batch through BulkImagePro’s JPG to WebP converter or the PNG to WebP converter. You end up with two sets of files — JPEG/PNG fallbacks and WebP primaries — ready to plug into your <picture> elements.

For a broader look at how WebP compares to legacy formats, our image compression guide breaks down the quality-to-size tradeoffs in detail.

The Lazy Loading Connection

Lazy loading and responsive images are separate techniques, but they interact in ways that matter. Get the interaction right and your pages fly. Get it wrong and you create weird visual bugs or accidentally sabotage your own performance.

Native Lazy Loading: The Two-Second Version

Modern browsers handle lazy loading with a single HTML attribute:

<img src="photo-800.webp"
     srcset="photo-400.webp 400w,
             photo-800.webp 800w,
             photo-1200.webp 1200w"
     sizes="(max-width: 600px) 100vw, 800px"
     alt="Below-fold content image"
     width="1200"
     height="800"
     loading="lazy">

The browser won’t download this image until the user scrolls near it. That’s bandwidth saved on initial load, which directly improves your first-paint metrics and reduces time-to-interactive.

The One Rule You Cannot Break

Never, ever lazy-load your LCP image. The hero banner, the featured product photo, the main content image — whatever the largest visible element is on initial page load, it must not have loading="lazy". Lazy loading tells the browser “don’t prioritize this,” which is exactly the opposite of what you want for your LCP element.

For LCP images, do the opposite:

<img src="hero-1200.webp"
     srcset="hero-800.webp 800w,
             hero-1200.webp 1200w,
             hero-1600.webp 1600w,
             hero-2000.webp 2000w"
     sizes="100vw"
     alt="Hero banner"
     width="2000"
     height="900"
     fetchpriority="high">

The fetchpriority="high" attribute tells the browser to download this image ahead of other resources. Combined with a preload hint in the <head>, you can shave hundreds of milliseconds off your LCP:

<link rel="preload" as="image" href="hero-1200.webp"
      imagesrcset="hero-800.webp 800w,
                   hero-1200.webp 1200w,
                   hero-1600.webp 1600w,
                   hero-2000.webp 2000w"
      imagesizes="100vw"
      fetchpriority="high">

How Sizing Interacts with Lazy Loading

Here’s a subtlety most guides skip: width and height attributes on lazy-loaded images aren’t just for CLS prevention — they also help the browser decide whether to load the image. Browsers use the reserved space to calculate whether an image is near the viewport. Without dimensions, the image takes up zero space initially, and the browser might miscalculate when to trigger the lazy load.

Always include width and height on every image, lazy-loaded or not. It prevents layout shifts and ensures lazy loading triggers at the right time.

Automating Responsive Images for CMS Workflows

If you’re working on a site where content editors upload images through a CMS, you need the responsive image generation to happen automatically. Nobody is going to manually resize every blog post image to five widths and convert it to WebP. That workflow breaks the first time a non-technical editor publishes a post.

Build-Time Generation

For static site generators (Astro, Next.js, Gatsby, Hugo, Eleventy), image processing typically happens at build time. Most frameworks have image components or plugins that take a source image and generate responsive variants automatically.

In Astro, for example, the built-in <Image> component handles this:

---
import { Image } from 'astro:assets';
import heroImage from '../assets/hero.jpg';
---
<Image src={heroImage}
       widths={[400, 800, 1200, 1600, 2000]}
       formats={['webp', 'jpg']}
       alt="Hero image" />

This generates all the variants at build time and outputs the proper <picture> element with srcset in the HTML.

Server-Side / CDN-Based Approaches

If build-time generation isn’t practical — maybe your images change frequently, or you’ve got thousands of them — consider on-the-fly resizing through your CDN. Services like Cloudflare Images, Imgix, and Cloudinary can resize and convert images at the edge based on URL parameters. You upload one high-resolution source image and request specific sizes via the URL:

https://cdn.example.com/images/product.jpg?w=800&format=webp

The CDN generates the variant on first request, caches it at the edge, and serves it for subsequent requests. Your srcset just points to different URL parameters:

<img srcset="product.jpg?w=400&format=webp 400w,
             product.jpg?w=800&format=webp 800w,
             product.jpg?w=1200&format=webp 1200w"
     sizes="(max-width: 600px) 100vw, 50vw"
     src="product.jpg?w=800"
     alt="Product">

The Hybrid Approach

For sites that aren’t using a CDN image service, the practical workflow looks like this: process your images before uploading. Use BulkImagePro’s bulk resizer to generate your size variants, convert to WebP with the format converter, and upload the full set to your CMS’s media library. Write a helper function or template partial that generates the srcset markup from a naming convention.

It’s not as seamless as automated build-time processing, but it works reliably, doesn’t depend on any third-party service, and the initial effort of generating responsive sets with a bulk image resizer pays for itself many times over in page speed improvements.

For teams that want to integrate image processing into their development pipeline, our developer API documentation covers programmatic access to BulkImagePro’s processing capabilities.

Stop Shipping 4000px Images to 375px Screens

Responsive images aren’t a nice-to-have anymore. They’re table stakes for any site that cares about performance, user experience, or search rankings. The good news is that the implementation is well-understood, browser support is excellent, and the tooling to generate multiple sizes is fast and free.

The workflow is straightforward: start with your highest-quality source images, generate variants at 400, 800, 1200, 1600, and 2000 pixels wide using BulkImagePro’s bulk resizer, convert to WebP with the format converter, implement srcset and sizes in your markup, lazy-load everything below the fold, and prioritize your LCP image. That’s it. Your mobile users get smaller files, your desktop users get sharp images, everybody’s happy, and Google stops docking you for slow page loads.

Resize your images in bulk with BulkImagePro — generate responsive image sets for free, right in your browser. Process up to 50 images at once with no signup, no uploads, and no server processing. Need to convert formats too? The JPG to WebP converter and PNG to WebP converter are built into the same workflow.

For the complete guide to batch resizing across every use case, see our bulk image resizing guide. Want to optimize file sizes further? Our image compression guide covers everything from quality settings to format selection.

Frequently Asked Questions

How many responsive image sizes should I generate?

Five sizes cover the vast majority of use cases: 400px, 800px, 1200px, 1600px, and 2000px wide. This range handles everything from small phone screens at 2x pixel density up to large desktop monitors. Going beyond five sizes adds storage and build complexity with diminishing performance returns. For most sites, this set delivers 80-95% of the bandwidth savings you'd get from pixel-perfect matching at every possible viewport width.

What's the difference between srcset and the picture element?

The srcset attribute provides the same image at different sizes, letting the browser choose the best match based on viewport width and pixel density. This is called resolution switching. The picture element serves completely different images (or different crops) at different breakpoints, which is called art direction. Use srcset when you just need size variants of the same photo. Use picture when you need different crops, different aspect ratios, or different compositions at different screen sizes. For most images, srcset with the sizes attribute is sufficient.

Do responsive images hurt SEO?

Responsive images help SEO, not hurt it. Google uses Core Web Vitals as ranking signals, and properly implemented responsive images improve your Largest Contentful Paint (LCP) score by ensuring mobile users download appropriately sized files instead of oversized desktop images. Google's crawler understands srcset and picture elements and indexes the appropriate image variant. The only caveat is to always include descriptive alt text on the img element, which is standard practice regardless of responsive image implementation.

Can I use a bulk image resizer to generate responsive image sets?

Yes. A bulk image resizer is the most practical way to generate responsive image sets. Upload your source images at full resolution, then batch resize to each target width (typically 400, 800, 1200, 1600, and 2000 pixels). Use a consistent naming convention like image-name-800.webp so your srcset markup can reference each variant predictably. BulkImagePro processes images directly in your browser, so you can generate all five sizes for 50 images in under two minutes without uploading anything to a server.

Should I lazy load responsive images?

Lazy load responsive images that are below the fold -- meaning they're not visible on the initial page load without scrolling. Add loading="lazy" to their img tags. However, never lazy load the hero image or any image that's the Largest Contentful Paint (LCP) element. For LCP images, use fetchpriority="high" and optionally a preload link in your HTML head. Lazy loading the LCP image delays its rendering and directly worsens your page speed score.

What image format should I use for responsive images?

WebP is the best format for responsive web images in 2026, offering 25-35% smaller files than JPEG with over 97% global browser support. For maximum compatibility, use the HTML picture element to serve WebP with a JPEG fallback. AVIF offers even better compression (around 50% smaller than JPEG) but has slightly less browser support and slower encoding, making it better suited for sites with CDN-based image processing. Generate your responsive sizes first with a bulk resizer, then convert to WebP using a format converter.