The browser you’re reading this on right now is probably not the same device as the person sitting next to you. One might be a 27-inch monitor at 2x pixel density, the other a five-year-old Android phone on a 4G connection. If your site serves the same 1200px image to both, one of them is getting a terrible deal.
Responsive images solve this. WordPress has had built-in responsive image support since version 4.4, but a lot of site owners don’t fully understand what that means in practice, or where it falls short. This article covers how it actually works, what to watch out for, and where you might need a plugin to fill the gaps.
What Responsive Images Actually Are
A responsive image is one that adapts to the device receiving it. Not just visually scaled down with CSS, but actually delivered at a different file size and resolution depending on the screen.
The point is efficient bandwidth use. There’s no reason to send a 1MB image to a 375px mobile screen when an 80KB version would look identical. Responsive images ensure each visitor gets the most useful version for their context, not the most generous one.
This matters more than it used to. Google’s Core Web Vitals measure Largest Contentful Paint (LCP), which is almost always an image on image-heavy pages. Serving oversized images is one of the most direct ways to degrade your LCP score.
How WordPress Handles This Automatically
When you upload an image to the media library, WordPress creates several size variants automatically. The default set includes:
- Thumbnail: 150x150px (cropped)
- Medium: max 300px wide or tall
- Medium Large: max 768px wide
- Large: max 1024px wide or tall
- Full: the original upload
WordPress then uses two HTML attributes to tell browsers which variant to use: srcset and sizes.
The srcset attribute lists all available image variants with their widths. The sizes attribute tells the browser how wide the image will actually be rendered at various viewport sizes. The browser uses both together to pick the most efficient option.
Here’s what that looks like in practice:
<img src="image-1024x683.jpg"
srcset="image-300x200.jpg 300w,
image-768x512.jpg 768w,
image-1024x683.jpg 1024w"
sizes="(max-width: 600px) 100vw,
(max-width: 1024px) 768px,
1024px"
alt="A descriptive alt text">WordPress generates this markup automatically for images inserted through the block editor or classic editor. You don’t write it by hand.
Things That Don’t Always Work as Expected
Understanding the mechanism is half the battle. Here are the edge cases worth knowing.
Your Theme Controls the sizes Attribute
WordPress generates a default sizes attribute, but it’s a conservative estimate. The actual rendered width of your image depends on your theme’s layout, which WordPress doesn’t know about in advance. A full-width hero image behaves very differently from a sidebar thumbnail.
If your theme is well-built, it should filter WordPress’s sizes output to reflect actual display widths. If it doesn’t, browsers may choose a larger variant than necessary. This is especially common with older themes.
srcset Is Not Implemented by Default in All Themes
If you’re using a theme that predates WordPress 4.4, or one built without responsive image support, the srcset and sizes attributes may not be present at all. Check by right-clicking an image on your site and inspecting the HTML. If you see only a single src attribute and no srcset, your theme isn’t using responsive images.
You can fix this either by updating the theme or by using a plugin that adds responsive image attributes retroactively.
Browser Behaviour Is Inconsistent
Browsers don’t all implement the srcset specification the same way. Most select the image closest to the viewport width, but some will prioritise a cached version of a larger file even if a smaller one is available. This means your responsive image setup may produce less consistent results across browsers than you’d expect.
For this reason, srcset should handle size variation but not design variation. If you want to show a different crop or a different composition of an image on mobile vs desktop, use the <picture> element instead, which gives you explicit control over which image loads under which conditions.
Image Dimensions Must Be Declared
For responsive images to prevent layout shift (a Core Web Vitals metric), the width and height attributes need to be present on <img> tags so the browser can reserve space before the image loads. WordPress does this for images uploaded through the media library. If you’re embedding images manually or via custom code, include both attributes explicitly.
Retina and High-DPI Displays
The responsive images setup above handles viewport width variation well. High-DPI displays introduce a separate consideration.
On a retina screen, the browser requests a version of an image at twice the pixel density (2x) to match the display’s physical resolution. If you only provide one version of an image, retina screens will upscale it, and the result looks slightly blurry compared to a native-resolution image.
The Perfect Images (WP Retina 2x) plugin handles this by generating 2x variants of your images automatically and adding them to the srcset so retina devices get the right version.
ShortPixel Image Optimizer is fully compatible with the Perfect Images plugin and will compress those retina variants automatically once you enable the option in ShortPixel’s Advanced settings, which is useful since 2x files are significantly larger than their standard counterparts.
When to Use a Dedicated Plugin
WordPress’s built-in responsive image support covers most scenarios well, but it has two gaps worth addressing.
The first is compression.
WordPress generates multiple image sizes, but it doesn’t compress them. Every size variant is stored at the same quality as your original upload. A compression plugin like ShortPixel Image Optimizer processes all your size variants, not just the originals, which compounds the savings significantly.
If you haven’t worked through the compression fundamentals yet, the image optimisation tips article covers format choice, quality settings, and what actually moves the needle on file size.
The second is adaptive serving. WordPress creates fixed sizes on upload. It doesn’t know, at the moment a page is requested, exactly how wide the image container is in the visitor’s browser. That means you still end up serving a variant that may be 150px wider than the actual rendered container.
ShortPixel Adaptive Images goes further by analysing the container dimensions at request time, generating an exactly-sized version, and delivering it from ShortPixel’s global CDN. It replaces the static size approach with a dynamic one, which eliminates the guesswork in the sizes attribute entirely.
For sites where image performance is a priority, it’s the most complete solution for responsive delivery. If you’re also thinking about how Google discovers and ranks your images, the WordPress image SEO checklist covers that layer separately.
In Conclusion
WordPress handles responsive images reasonably well out of the box, but the default setup leaves real optimisation on the table. Your theme needs to support srcset for any of this to work, the sizes attribute benefits from being tuned to your actual layout, and high-DPI screens need retina variants that WordPress doesn’t generate automatically. And lastly, compression across all size variants requires a separate plugin.
None of this is complicated once you understand the mechanics. The main thing is not to assume it’s all working correctly without checking. A quick right-click inspect on a post image tells you immediately whether srcset is present and what sizes WordPress is offering the browser.
