---
title: Responsive Images & `srcset`
pub_date: 2013-09-30 20:08:57
slug: /blog/2013/09/responsive-images-srcset
metadesc: A comprehensive overview of responsive images and the srcset attribute. Regularly updated to keep up with changing standards proposals.
code: True
tags: Responsive Images
---

[Note: This post is superseded by the fact that the picture element now exists. Picture supports srcset as well, so you can do everything I mention below, you just do it within `<picture>`. See my [complete guide to the picture element](https://longhandpixels.net/blog/2014/02/complete-guide-picture-element) for more details.]

There are, in my experience, three pain points in any responsive design -- tabular data, advertising and images. The latter is the most interesting problem to me since it's not something you can design or engineer your way around. True, there are ways you can coerce today's browsers into doing roughly what you want -- serve large images to large screens and small ones to small screens -- but these are really hacks, sometimes very clever hacks, but still hacks. 

Nathan Ford has put together a nice [Responsive Images Mega-List][1] in an attempt to catalog all the ways you can handle images in a responsive site today.

That's a great list of resources for handling images today, but what I've been obsessing over lately is the future, when we won't need all these workarounds.

Just like we hacked video into the web using Flash and eventually got the `<video>` tag, we're hacking responsive images into the web and eventually the web is going to give us a native solution. In fact, there's one just around the browser update bend. 

## How `srcset` Simplifies Responsive Images

The exciting thing is that there are not just one, but two responsive image solutions already in the works. The W3C is working on a couple of new tools aimed at making responsive images less complex. The first new feature that's likely to make it to a browser near you is the new `srcset` attribute for the `<img>` tag.

[**Update 27 Feb 2014**: Chrome has [added support](http://blog.chromium.org/2014/02/chrome-34-responsive-images-and_9316.html) for `srcset`, which means it will land in Opera soon as well. The Chrome implementation mirrors what's described below for WebKit. At the same time the `srcset` attribute has been added to the proposed `<picture>` element which you can read about in my [Complete Guide to the <Picture> Element](https://longhandpixels.net/blog/2014/02/complete-guide-picture-element).]

The proposed `srcset` attribute has a controversial history, which I wrote about [several][2] [times][3] on Webmonkey. I don't think any of that matters at this point though. It's true that `srcset` doesn't address everything about responsive images, but it looks to me like it covers the 80 percent use case and, more importantly, there is [already some browser support][4] (and more on the way). 

Here's how `srcset` works:
    
~~~.language-markup
<img alt="Image Desc"
   src="image.jpg"
   srcset="image-HD.jpg 2x, image-phone.jpg 320w, image-phone-HD.jpg 320w 2x">
~~~

As you can see, the `srcset` attribute takes a comma-separated list of values. Within each item in the list you have three variables. First there's the URL to the image, then there's a maximum viewport dimension (optional) and then an optional pixel density (for targeting higher resolution screens). So the `srcset` value `image-HD.jpg 2x` tells the browser, roughly, if you're on a display with high-res screen then grab this high-res image. Pretty simple. You can of course make it much more complex by adding several other images to the list, for example, to target various screen widths.

There are two major drawbacks to `srcset`. First, **you can only specify screen width (or height) in pixels**. The reason has to with how browsers pre-fetch content, which happens long before there's enough info to calculate the value of a percentage or em width/height. See this [thread on the W3C mailing list][5] for details. The bottom line is, flexible units for `srcset` is a no-go.

The other major drawback is that **you can only specify the equivalent of max-width** when defining the viewport dimensions. There is no min-width or orientation support like you'd use in CSS @media queries. That means you may not be able to line your `srcset` breakpoints up with your CSS breakpoints.

There's some other stuff in the spec worth noting as well. For instance, "if the viewport dimensions or pixel density changes, the user agent can replace the image data with a new image on the fly." That means (I think) that, while there's no equivalent to CSS 3 @media's `orientation` query, you could get the same effect because the viewport dimensions change on rotation, triggering larger images to load (though to make that work you'd end up targeting specific device widths, which is not [future-friendly][6]). It's hard to imagine a scenario in which the pixel density would change, but hey, why not I guess?

There is one very cool part of the spec though, it puts the ultimate decision about which images are served in the hands of the user. 

No browser supports it, but the spec says that the higher res images specified in `srcset` are just candidates. Here's the [relevant bit][7]:

> Optionally, return the URL of an entry in *candidates* chosen by the user agent, and that entry's associated pixel density, and then abort these steps. The user agent may apply any algorithm or heuristic in its selection of an entry for the purposes of this step.

So in theory the browser gets the final say. This means the browser can check the available network and make a decision about whether or not to actually obey `srcset`. For instance it might reject the high-res images on 3G, but accept them over wifi. Even better, mobile browsers could add a user preference so users can say (as they can today with native apps), "I only want high-res images over wifi". Or all the time or whatever. The user is in control.

I think that's probably the best way to handle what's possibly a user-developer conflict. For example, I want my images to look good on your retina iPad, but you might want to save your (possibly) expensive bandwidth for other things. I think the user should trump the developer in that scenario. With `srcset` the browser can give the user the power to make that decision.

## Testing `srcset` Today

This is all largely academic right now. Only one browser supports `srcset` and even that's just the nightly builds of Apple's WebKit.

If you want to see it in action, go grab the [latest WebKit nightly][8]. Here's a live demo:

<img src="/media/images/demos/srcsetdemo-fallback.jpg" srcset="/media/images/demos/srcsetdemo-2x.jpg 2x" alt="demo of srcset in action" width="660"/>
This first test is for retina displays, which looks like this:

~~~.language-markup
<img alt="demo of srcset in action"
  src="/media/images/demos/srcsetdemo-fallback.jpg" 
  srcset="/media/images/demos/srcsetdemo-2x.jpg 2x"  />
~~~

<img src="/media/images/demos/srcsetdemo-fallback.jpg" srcset="/media/images/demos/srcsetdemo-widthquery.jpg 420w" alt="demo of srcset in action" />
This test is for mobile screens with a maximum viewport of 420px, here&#8217;s the code:

~~~.language-markup
<img alt="demo of srcset in action" 
    src="/media/images/demos/srcsetdemo-fallback.jpg" 
    srcset="/media/images/demos/srcsetdemo-widthquery.jpg 420w" />
~~~    

<img src="/media/images/demos/srcsetdemo-fallback.jpg" srcset="/media/images/demos/srcsetdemo-mobile2x.jpg 420w x2" alt="demo of srcset in action" />
The last test is for mobile high res screens and uses this code:

~~~.language-markup
<img alt="demo of srcset in action"
    src="/media/images/demos/srcsetdemo-fallback.jpg" 
    srcset="/media/images/demos/srcsetdemo-mobile2x.jpg 420w x2" />
~~~   

<img src="/media/images/demos/srcsetdemo-fallback.jpg" srcset="/media/images/demos/srcsetdemo-superwidequery.jpg 9000w" alt="demo of srcset in action" />
This final test is designed to check WebKit's current implementation, which does not yet support specifying a width. It's the same query as above, but with a much wider max-width which should trigger it to load in desktop WebKit Nightly.

~~~.language-markup
<img alt="demo of srcset in action"
    src="/media/images/demos/srcsetdemo-fallback.jpg" 
    srcset="/media/images/demos/srcsetdemo-superwidequery.jpg 9000w"  />
~~~
    

As of September 30, 2013, using the latest WebKit Nightly (v8536.30.1, 538+) only the first test works. WebKit only supports the pixel density queries, not the max viewport width query.

## Which Web Browsers Support `srcset`?

Eventually caniuse.org will probably [add][8] `srcset` (I think they require at least one shipping version of the feature before they'll track it), but for now I threw together a table for keeping track of which web browsers support `srcset`.

Here's the list as of November 15, 2013:

<div class="longtable">
<table>
<colgroup>
<col style="text-align:left;"/>
<col style="text-align:left;"/>
</colgroup>

<thead>
<tr>
	<th style="text-align:left;">Browser</th>
	<th style="text-align:left;"><code>srcset</code> support</th>
</tr>
</thead>

<tbody>
<tr>
	<td style="text-align:left;">WebKit Nightly</td>
	<td class="yes" style="text-align:left;">yes</td>
</tr>
<tr>
	<td style="text-align:left;">Safari 7</td>
	<td class="no" style="text-align:left;">no</td>
</tr>
<tr>
	<td style="text-align:left;">Firefox 30</td>
	<td class="no" style="text-align:left;">no</td>
</tr>
<tr>
	<td style="text-align:left;">Chrome 34+</td>
	<td class="yes" style="text-align:left;">yes</td>
</tr>
<tr>
	<td style="text-align:left;">Opera 16</td>
	<td class="no" style="text-align:left;">no</td>
</tr>
<tr>
	<td style="text-align:left;">IE 11</td>
	<td class="no" style="text-align:left;">no</td>
</tr>
<tr>
	<td style="text-align:left;">Mobile Safari 7</td>
	<td class="no" style="text-align:left;">no</td>
</tr>
<tr>
	<td style="text-align:left;">Opera Mini 7</td>
	<td class="no" style="text-align:left;">no</td>
</tr>
<tr>
	<td style="text-align:left;">Opera Mobile 14</td>
	<td class="no" style="text-align:left;">no</td>
</tr>
<tr>
	<td style="text-align:left;">Android Default 4.2</td>
	<td class="no" style="text-align:left;">no</td>
</tr>
<tr>
	<td style="text-align:left;">Chrome for Android</td>
	<td class="no" style="text-align:left;">no</td>
</tr>
<tr>
	<td style="text-align:left;">Firefox for Android</td>
	<td class="no" style="text-align:left;">no </td>
</tr>
</tbody>
</table>
</div>

Yes, it's a slightly ridiculous table, <strike>but with any luck Chrome will be joining the list of <code>srcset</code> supporters in the very near future</strike>. [**Update 2014-02-27**: Chrome 34 and higher [now support](http://blog.chromium.org/2014/02/chrome-34-responsive-images-and_9316.html) `srcset`, which also means Opera will soon as well]. My contacts at Mozilla tell me that Firefox is also working on support. So things are looking pretty good for the future. That doesn't help today though, so if you need something now, remember to check out Nathan Ford's [Responsive Images Mega-List][1] for a complete collection of responsive image solutions that work today.

[1]: http://artequalswork.com/posts/responsive-images/ (Responsive Images Mega-List)
[2]: http://www.webmonkey.com/2012/05/ready-or-not-adaptive-image-solution-is-now-part-of-html/ (Ready or Not, Adaptive-Image Solution Is Now Part of HTML)
[3]: http://www.webmonkey.com/2012/05/browsers-at-odds-with-web-developers-over-adaptive-images/ (Browsers at Odds With Web Developers Over 'Adaptive Images')
[4]: http://mobile.smashingmagazine.com/2013/08/21/webkit-implements-srcset-and-why-its-a-good-thing/
[5]: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0310.html
[6]: http://futurefriend.ly/
[7]: http://www.w3.org/html/wg/drafts/srcset/w3c-srcset/#processing-the-image-candidates
[8]: http://nightly.webkit.org/