By Annarita Tranfici

Responsive Images, Part 1: Using srcset

By Annarita Tranfici
Help us help you! You'll get a... FREE 6-Month Subscription to SitePoint Premium Plus you'll go in the draw to WIN a new Macbook SitePoint 2017 Survey Yes, let's Do this It only takes 5 min

Responsive Images

  • Responsive Images, Part 1: Using srcset

Today, I’ll give you some new food for thought on an aspect of Responsive Web Design (RWD) that is very popular right now: responsive images. RWD is not a new topic but its approach is not always easy and free of pitfalls. Especially when it comes to images, there are many unresolved issues.


During the development of a website, we can encounter several difficulties in the management of the images. Bearing in mind the primary need for their smooth and proper display on a wide variety of devices, these difficulties may include:

  1. Proper optimization and weight reduction;
  2. Attention to unnecessary waste of bandwidth (we all know how the loading speed of a website is one of the major factors for the success or failure of our own website);
  3. Appropriate resolution for the device in use.

For the first problem, tools like TinyPNG and JPEGmini can help in reducing images’ weight and optimize them.

For the second problem, on several occasions we’ve had the possibility to test the great potential of media queries. Thanks to them, we’ve an easy method to face the problem for background images, that is those we show using the CSS rule background-image. However, considering that this solution cannot be applied to images shown using the <img> tag, how could we resolve the third and last problem and set the right image resolution for the device we’re using to visit a website?

In this case, there are two proposed solutions that come to the rescue: the <picture> element and the srcset attribute of the <img> tag.

In this article, I’ll give you a general overview of the srcset attribute, while the <picture> element will be the topic of the very next article.


The srcset attribute

What is the main benefit we can gain from the use of this attribute? Thanks to it, web developers can target users on high-resolution displays with a high-resolution image source or different types of screens with other versions of images. In the first case users on lower pixel density displays won’t be saddled with the wasteful bandwidth cost of downloading a useless massive high-resolution image, while the latter can enjoy the power of their screen. In the second situation, we can specify a different image for different screen sizes, in order to provide an image that is more focused on the users’ device.

The srcset attribute, in fact, allows us to specify a list of sources for an image, which will be delivered based on the pixel density or size of the user’s screen. So we can say that implementing the srcset attribute is a good way to provide to the browser a set of “suggestions” about the correct behavior it should have with a certain type of image. By doing so, we improve the loading of our page and the experience of our users.

At this point, let’s see the basic characteristics of this attribute, the conditions to specify to make it work and the way to implement it in our code.

As the W3C states, The srcset attribute allows authors to provide, in a compact manner, multiple variants of the same image at differing resolutions or for different viewport dimensions. User Agents may make their resource selection before fetching any of the resources, thus avoiding multiple resource loads and the associated performance problems in constrained bandwidth environments.

The srcset attribute includes a series of comma-separated values which, on one hand, specify an image URL and, on the other hand, the conditions under which the image will be shown. Among these conditions we can find pixel density, viewport width, or both of them. A very interesting point is that the browser, based on some heuristics or user settings, can interpret what’s best for the user at the time of the page visit, and choose if fetching a lower resolution image or a high-resolution one.

Envision a preference in your mobile browser allowing high-resolution images to be requested, for instance, only while connected to WiFi, or a manual browser preference allowing you to only ask for low-resolution images when the connection is weak.

The code syntax is the following:

<img src="small-photo.jpg" srcset="big-photo.jpg 2x" />

This short piece of code asks the browser to show the image with name small-photo.jpg unless the device has a high-resolution display (pixel density 2x, like the Retina). Please note that the other photo will be displayed only if the browser understands how to handle the attribute. The browsers that fail to interpret in a correct way the attribute will simply ignore it and show the fallback image that you have previously specified in the src attribute.

As noted, this attribute isn’t only good for density. In those situations where it deals with the width of the screen, we can imagine it as a sort of equivalent to the max-width property of the media queries. To benefit from it, you have to specify the number of pixels followed by a w (for example 600w). To better understand this case, let’s see another example taking a beautiful shot called “Autumn in Moscow” from the website Sxc.hv, the dimensions of which are are 1368×700 and the weight (after optimization) 389Kb:

Autumn in Moscow

Based on what we’ve discussed so far, what’s the advantage of letting a user surfing the Web with their smartphone download an image of a size bigger (and then heavier) than the one his device can display? Moreover, please remember the limitations of the mobile connection, a tough problem because the image will slow the loading of your page and this could lead your users to quit your website (the first thing to avoid, obviously). Having said that, what you can think about is using the same image but smaller, in size (400×225) and weight (~40Kb), as shown below.

Autumn in Moscow

It’s incredible how we can let users save bandwidth and improve their experience with just the following little shrewdness:

<img src="low-density-photo.jpg" srcset="small-photo.jpg 480w, big-photo.jpg 1024w, high-density-photo.jpg 1024w 2x" />

This snippet uses the low-density-photo.jpg image as fallback and indicates a list of images for a certain number of different conditions: small-photo.jpg will be used for devices having a screen width less or equal to 480px, big-photo.jpg for devices with a screen width less or equal to 1024p and the last, high-density-photo.jpg, for devices with a screen width less or equal to 1024px and a high-resolution display.

Now, I have some less good news for you. The only browsers that support srcset are the WebKit ones, Actually, since Chrome has moved to the Blink engine, we have to clarify that Chrome doesn’t support it anymore, eiher.

In addition, you cannot set an image based on the max-width of the device’s screen, because the proposal implemented didn’t specify this possibility. The question is a little bit complicated, so check for updates constantly and read more about its specifications and the ways to implement the technique in your projects.

An Editor’s Draft of the W3C specification for srcset has been released just today, the 2nd of December. It includes some good and clear examples of the use of this attribute.

Being an Editor’s Draft, we can also say this brings the adoption of the attribute a little closer, giving all browsers motivation to accept and respect use of the srcset attribute. We can only hope.


In this article we’ve described how the srcset attribute could help developers in a better management of their websites’ images. Nevertheless, as we’ve seen, support among browsers is lacking but we are hopeful and confident that this problem will be solved very soon.

In the next article, I’ll compare the srcset attribute with the <picture>element, to see how the latter stacks up.

Login or Create Account to Comment
Login Create Account
Get the most important and interesting stories in tech. Straight to your inbox, daily.Is it good?