Responsive Images and SEO: srcset Guide 2026

Administrator in Search Engine Optimization Oct 09 / 1 week ago

The browser, not you, picks which image file to download, and it makes that choice before the page has finished loading. MDN Web Docs explains that images start downloading before the browser has read the page's CSS and JavaScript. A script cannot swap in a smaller photo later, because the large one is already on its way. What you control is the list of files you hand over and how honestly you describe it.

My view: responsive images are a menu you give the browser, not an order. Describe each file's real width and the real slot on the page, keep a plain fallback, and let the browser choose. I think most waste comes from a missing or lazy sizes value, not from too few files.

What are responsive images, and which two problems do they solve?

Responsive images give the browser more than one file to choose from, and each device can then load a version that fits. MDN names the two problems they solve: the "resolution switching problem", the same photo at different sizes, and the "art direction problem", a different crop for a different layout.

MDN's guide, last modified on November 6, 2025, says srcset, sizes and the picture element "are all supported in modern desktop and mobile browsers".

Do responsive images matter for SEO?

Responsive images matter for speed and for the people on your page. Google's image SEO guide, updated March 2, 2026, says responsive pages lead to "better user experience". It also asks you to "always specify a fallback URL using the src attribute", and gives a plain reason about srcset and picture: "However, some browsers and crawlers don't understand these attributes".

Google can find images in the src attribute of an image element, even inside a picture element, but "Google doesn't index CSS images". Google adds that sharp images are more appealing to users in the result thumbnail, and that images are often the largest contributor to page size. A web.dev guide by Katie Hempenius, last updated November 5, 2018, covers the speed side: if the Largest Contentful Paint element is an image, serving it responsively can reduce its load time and improve your LCP score. Our Core Web Vitals guide shows how to measure it. Google also suggests an image sitemap for images it might miss, which our XML sitemap guide covers.

How does srcset with width descriptors work?

The srcset attribute is a list of files, each paired with its real width in pixels, written with a w, such as 480w. The sizes attribute then tells the browser how wide the slot on the page will be, and the browser compares the two and picks a file that fills the slot sharply.

MDN lists what the browser looks at: screen size, pixel density, zoom level, screen orientation and network speed. With no exact match, it takes the first bigger file and scales it down. In MDN's example, the 800 pixel photo is 128 KB and the 480 pixel version is 63 KB, a saving of 65 KB.

What does the sizes attribute do, and what if you leave it out?

The sizes attribute tells the browser how wide the image will be in the layout at each screen width. It does not change the display size, which is still the job of CSS. Leave it out and the browser assumes the image fills the full screen width, and in my view that is the most common source of waste.

The last entry in sizes has no condition and acts as the default, and order matters, because MDN warns that "The browser ignores everything after the first matching condition". The WordPress 6.7 note spells out the cost of leaving it out: "Without any value, browsers will use the default 100vw value and assume the image is meant to fill the entire width of the viewport, resulting in many wasted bytes".

When are density descriptors enough?

Density descriptors are enough when the image shows at one fixed size on every screen, such as a small author photo or a product badge. You list a normal file and a sharper one marked 2x, and you skip sizes. The browser weighs the screen's device pixel ratio, and MDN notes that 1x is implied.

In MDN's example, the 640 pixel file is 93 KB and the 320 pixel file is 39 KB. web.dev, in a lesson last updated February 1, 2023, warns that 2x describes "a double density image" and is not an instruction. web.dev also cites data shared by Matt Hobbs: about 18 percent of GOV.UK browsing sessions from November 2022 reported a device pixel ratio of 1.

Why does the browser get the final say?

The browser decides because it knows things you cannot, like the connection, the cache and the user's data settings. web.dev says the selection rules in the HTML specification are "explicitly vague" by design. Once it has your list and sizes, the browser "is free to do whatever it wants", and you cannot know for certain which file it will choose.

web.dev notes that pixel density is only loosely tied to connection speed, and a person with a sharp laptop on a metered connection may want small files. Most browsers also will not request a smaller file than one already in the cache. My view: your job is to describe, and the browser's job is to decide.

When do you need the picture element?

Use the picture element for two jobs: a different crop on different screens, and new formats with a safe fallback. Each source element inside it carries a media condition or a type, and the first match wins. It must end with a normal image element with a src and alt text, which MDN says you need, "otherwise no images will appear".

web.dev calls picture a "decision engine" for the image inside it, and browsers that do not know picture just show that inner image. It also says most cases based on screen size "can be more efficiently handled with" srcset and sizes.

New formats are the second job: web.dev explains that a browser without WebP support skips a source whose type it cannot decode, without requesting the file, and loads the inner JPEG or PNG. Google says picture helps with new formats "with built-in graceful degradation". Format choice lives in our image optimization guide, and searching with a phone camera is the subject of our visual search guide.

Which technique fits which image?

Use srcset with width descriptors and sizes for photos that change width on different screens, density descriptors for fixed-size images, and picture only for new crops, new formats or user preferences. Keep anything you want in Google Images out of CSS backgrounds. The table below sums up each case and names its source.

The third column paraphrases Google, MDN, web.dev and WordPress pages, saved on October 8, 2026. The second is our advice.

How many sizes should you make, and what does WordPress do for you?

An older web.dev guide from 2018 says it is common to serve three to five sizes of an image, and that there is no single correct number. WordPress 4.4 began adding srcset and sizes to the image markup it generates, using the sizes it makes of each upload. Its default sizes value is a starting point that themes should customize.

The WordPress 4.4 note, dated November 10, 2015, caps candidates at a default maximum width of 1,600 pixels. It also added a 768 pixel medium large size, and it leaves alone any srcset or sizes already in your content. Our WordPress defaults guide covers the rest, and our Squarespace guide notes that Squarespace serves image variants on its own.

How do responsive images work with lazy loading?

Lazy images wait until the page layout is known, so the browser can measure the real slot itself. That is the idea behind sizes set to auto. WordPress 6.7 adds it to lazy-loaded images, and the browser then uses the rendered width when it picks a file from the srcset list.

web.dev's prescriptive lesson called sizes set to auto "proposed" on February 1, 2023. By October 18, 2024, the WordPress 6.7 note said it had been added to the HTML specification, with "many fewer wasted bytes" for lazy images. WordPress adds auto only to lazy images, because on an image that is not lazy, browsers that support auto would fall back to the full screen width and pick larger files. Our lazy loading guide covers which images to load late.

What does this look like for a store, a studio and a guesthouse?

The method for responsive images stays the same everywhere: describe the files, describe the slot, keep a fallback. A store banner may need a new crop, a photo-heavy portfolio needs honest widths, and a grid needs a sizes value with two slots. The three examples below are invented to show each pattern.

For example, a Denver, Colorado outdoor gear store has a wide homepage banner of hikers. On a phone the hikers shrink to dots, and the picture element can serve a tighter crop to narrow screens. Its product and category templates only need width descriptors and an honest sizes value, and our product page guide and category page guide cover those templates.

For example, an Amsterdam, Netherlands architecture studio shows full-width project photos with four widths in srcset and a sizes value for the full screen minus its side margins.

For example, a Busan, South Korea guesthouse shows room photos in two columns on desktop and one column on phones. Its sizes value has two slots: about half the screen above a set width, and the full screen below it. If Naver matters to you too, our Naver guide covers Korean search.

How do you check that the right file loads?

Open the page in Chrome DevTools or Firefox DevTools, turn off the cache, and watch the network panel as you resize the window, which is how MDN suggests seeing which file loaded. Then confirm every image still has a real src fallback, because Google says some browsers and crawlers do not understand srcset or picture.

web.dev's 2018 guide points to a Lighthouse audit called Properly size images, which lists images still to resize, but confirm the audit name in your current Lighthouse version. For the wider picture, see our Search Console guide, our technical SEO audit guide and our mobile-first indexing guide. Social share images follow other rules, covered in our Open Graph tags guide.

In my view, responsive images reward honest descriptions more than extra files. Give every image a real src, and build width descriptors from the sizes your CMS already makes. Write sizes from the real layout, slot by slot, and use picture only for new crops and new formats. Then, as our own rule, load one URL per template with the cache off, and confirm the file that arrives fits its slot.

Frequently asked questions

Does srcset replace the src attribute?

No, keep both. Google's image SEO guide says some browsers and crawlers do not understand srcset or the picture element, and it recommends that you always give a fallback URL in the src attribute. Browsers without srcset support simply load that file. The 2018 web.dev guide adds a tip: make the src file large enough to work well on all device sizes, and my advice is to point it at one of the larger files in the same list, not a thumbnail.

Can the sizes attribute use percentages?

No, MDN says you cannot use a percentage as the slot width, and the 2018 web.dev guide says the same. Use a length instead: MDN allows an absolute width in pixels or a width relative to the viewport, and the same web.dev guide also lists em units and calculated values. web.dev explains why the viewport matters: the browser picks a file from the list before it has the page layout, and at that point the viewport is the only layout fact it has.

What happens to responsive images in older browsers?

They still get an image: MDN says older browsers that do not support these features ignore them and load the src file as normal. The picture element degrades the same way, and web.dev explains that a browser that does not know picture ignores it, discards the source elements, and shows the inner image. The 2018 web.dev guide also notes that srcset and sizes arrived together, and every browser supports both or neither. That is why the real src fallback is never optional.

Does the order of media conditions matter?

Yes, in both places: in the sizes attribute, MDN warns that the browser skips every entry after the first one that matches, and web.dev says the same. Inside the picture element, the first source that matches wins. web.dev advises putting the largest source first when you use min-width conditions, the smallest first with max-width conditions, and the inner image always last. Get the order wrong and the browser may stop at a slot or source you never meant it to use.

Can JavaScript swap in a smaller image instead?

Not well: MDN explains that the browser starts downloading images before it reads the page's CSS and JavaScript. By the time a script measures the screen, the large file is already loading, and a swap means the phone downloads two files. web.dev describes older script fallbacks for new formats that wasted a request in a similar way. Lazysizes takes a different route: web.dev says it waits for layout before requesting images and lets JavaScript write sizes, trading some speed for efficiency.

Will the browser download two versions of the same image?

Usually not, because web.dev says that in most browsers, an image using srcset or sizes will not request a file smaller than one already in the cache. If a visitor widens the window enough that a bigger file is needed, the browser will request it, and that second download is expected. MDN suggests turning off the cache in Chrome when testing, to stop it from picking an image it already downloaded. In my view, a script that swaps files is the bigger risk.

Do I need a JPEG source inside the picture element?

No, web.dev says you do not need a second source element for JPEG, because you can assume every browser supports it. Put the new format, such as WebP or AVIF, in a source element with its type, and put the JPEG in the inner image's src. Google Search supports BMP, GIF, JPEG, PNG, WebP, SVG and AVIF in the src attribute, and it suggests that the file extension match the file type. web.dev adds that the whole choice costs a single file transfer.

Should a hero image be a CSS background?

Only if the image is pure decoration and you never need it found. Google's image guide states that "Google doesn't index CSS images", and it finds images through the src attribute of an image element. MDN's own example uses a CSS background for a header image that exists only for decoration. My view: if the photo shows your product, place or team, use an image element with srcset and sizes, and keep CSS backgrounds for textures and patterns you would never want in Google Images.

Can the picture element switch images for dark mode?

Yes, web.dev says art direction is not limited to screen size, and it shows a source that matches a user's dark color scheme preference. The browser checks the media condition and picks the dark version when it matches, and the light version stays in the inner image as the fallback for every browser. My view: use this for charts, diagrams or logos that become hard to read on a dark page, not for every photo, because each version is one more file to maintain.

Do responsive images need their own alt text?

No, every file in the list is a version of the same image, and one alt text covers all of them. MDN says the picture element must end with an image element that has a src and alt text, and that inner image carries the description for every source. My view: write one alt text per image element, never per file, and our alt text guide covers how to write it. Google says it reads alt text alongside the page content to understand what an image shows.