Photograph of a blurred waterfall in Iceland with a conical mountain behind it

Last year Apple released a “Retina”-screen iMac, making it official: we are now in the world of desktop high-DPI screens. This makes the job of designers and developers doubly difficult, expanding an image quality problem that was previously confined to mobile devices and high-end laptops to one that will soon reach computers everywhere.

Thankfully, HTML5 now has a solution. But before looking at that, we should have a better understanding of the Retina problem.


The ideal solution would be to send high-resolution versions of images to devices that can use them, while maintaining a standard resolution for others. The srcset attribute with the x designator does just that:

<img src="kirkjufell.jpg" srcset="kirkjufell.jpg 1x, kirkjufell@2x.jpg 2x" alt="Photograph of a blurred waterfall in Iceland with a conical mountain behind it">

This delivers the kirkjufell.jpg image to standard screens, and kirkjufell@2x.jpg to those that are 196DPI or higher. Browsers that don’t support srcset will fall back to the file specified in src, absent a polyfill. It’s also possible for the browser to make decisions on which image version to use based on zoom level or even network conditions. As with <picture>, alt contains the alternative text of all the collective images in the element.

Note that the @2x appended to the filename is not required: it’s just a suggested naming convention for high-DPI images. I’ve embedded 1x and 2x in the example so you can see which version is picked up on different devices.

Browser Support

Browser support for srcset is quite good at the time of writing: Chrome 34+, Safari 7+, Microsoft Edge, Opera 21+, Firefox 38+ and iOS8 all support the basic syntax, together with the latest versions of Chrome for Android and Opera Mobile. To gain support in all other browsers use picturefill, discussed extensively in the previous article.

Do You Need @2x Images?

All of this is wonderful, but rather begs the question: do you actually need to have @2x and @3x images on your site? Does the extra work actually make a significant visual difference?

While the answer is ultimately subjective, experimentation has led me to two conclusions:

  • @2x makes a difference if you are compressing bitmapped images as you should be. A 40% “quality” JPEG will, in many cases, scale up well on a Retina display, at the cost of a significant file size. A 15% JPEG will load much faster and look fine on a standard display, but have visible artifacts on a high-DPI screen. srcset bridges these problems with one elegant solution.
  • Fine details matter. Bitmap UI elements often suffer on Retina screens. In most cases, you should consider using SVG for icons, rather than srcset.
  • A red square is a red square: it’s not going to be improved for Retina by having 4× its original pixels added to it: not every image will benefit from having a doubled (or tripled) clone.

Application Support

Due to the fact that it’s been supported in browsers for longer than <picture>, applications like Sketch and Adobe PhotoShop have some awareness of srcset. However, most workflows suggest enlarging a bitmap before saving it in @2x format, which simply transfers the scaling problem from the browser to the bitmap editor. In my opinion it’s better to start with the largest version in the editor, saving it at an appropriate size as the @2x version, then reducing it to produce the 1x version. Of course, there are also server-side and CMS tools to do the same automatically: I’ll have much more information about those approaches in future articles.

Where Should srcset Be Used?

Given its strong support across multiple browsers, combined with the fact that the polyfill is robust and fallback so graceful, I see little reason not to use srcset in modern web development, using either the x or w syntax. Of course, doing so potentially comes at the cost of doubling (or even tripling) the number of image files in a site, so the transition will require close attention to tooling, workflow, role responsibilities and CMS support: I’d suggest starting with banner and hero images, given that these are usually the largest and most visually impressive features on a site, and would likely benefit most from the attention. This could also be combined with art direction via <picture>, discussed previously.

Photographs by Stian Klo, licensed under Creative Commons.