Web Platform Team Blog

Making the web awesome

Responsive Images for HTML5

The HTML image tag has been around about as long as HTML itself. In nearly 20 years the tag has changed very little, in spite of the essential role that images play in most Web content. During that same period of time, the capabilities of the devices people use to view Web content have changed dramatically. For the longest time Web content seemed to assume a world where color displays had a pixel density of roughly 96 dpi and a viewing area of about a million pixels. This fiction persisted much longer than it should have because it’s just easier to target one kind of display. In the past five years or so, reality has intruded. Web developers must now deliver content that looks good on relatively huge desktop displays and televisions, as well as relatively small phones and tablets with pixel densities of 150 dpi or more. The resolution of Apple’s eye popping Retina displays can be over 300dpi, roughly the same as their original (monochrome) laser printer. All of this power and diversity creates some problems for the old HTML IMG tag:

  • Authors would like to specify different images, depending on size of the available screen real-estate
  • Similarly, authors would like to specify different (bigger) images for high-pixel-density displays
  • Authors would also like to be able to specify alternative images when the available bandwidth is low
  • Sometimes “different” just refers to an image’s size, sometimes it’s how the image is cropped

JavaScript Solutions, Preloading

One can overcome many of these problems by writing JavaScript that tries to do the right thing in light of the characteristics of the display the page has landed on. Unfortunately, doing so runs afoul of a browser feature called “preloading”. Downloading, parsing, and executing a Web page requires a great deal of waiting. Modern browsers fill this time by eagerly preloading various elements, notably images. This makes the overall process of displaying a new page go much faster. Users love this. It makes the Web feel more “responsive”. So if we want a solution that’s also responsive to the wide variety of modern displays, we have to be careful not to create an image preloading obstacle.

Debate About an HTML Solution

In roughly the past twelve months there has been a great deal of discussion about exactly how to support “responsive images”; about the best way to deal with the problems listed above. Several solutions have been proposed and championed – notably a new picture element – and many expert Web authors and browser implementers weighed in via email, forums, blogs, on IRC, and probably in person. Finally in May, a new IMG tag attribute called “srcset” made its debut in the WhatWG HTML5 spec. If you’d like to review the rationale for this particular solution, you might start with the WhatWG email archive. Similar support for CSS images has also been proposed. In fact the CSS image-set function recently made its debut in WebKit.

New HTML IMG Attribute: srcset

The new srcset IMG attribute enables specifying a set of images to handle displays of different sizes and pixel densities. The value of the srcset attribute is a specially formatted string that enumerates the URLs for a set of alternative images, the pixel density of the display they’re intended for, and the maximum viewport size they’re intended for. The string itself is a comma separated list of image URLs followed by optional size and pixel density qualifiers. The srcset syntax is easiest to explain with a few examples:

<img alt="robots" srcset="robots.jpg 1x, robots-HD.jpg 2x">

In this case we’ve specified two versions of an image, “robots-HD.jpg” for double-density displays and “robots.jpg” for regular displays. The IMG src attribute is now equivalent to specifying a srcset image with (just) “1x”, so this can be shortened slightly to:

<img alt="robots" src="robots.jpg" srcset="robots-HD.jpg 2x">

Here’s a rough approximation to how this srcset example might appear on a pair of screens: a normal pixel density display on the left, and a double density display on the right.



The tidy “2x” device pixel density qualifier means that one CSS pixel maps to two device pixels. Typically, when a pair of images is specified in this way, the 2x image is twice as big as the 1x version so that they’ll both occupy the same CSS pixel area. A display screen’s pixel density and its real physcial resolution are only loosely coupled: the 1x and 2x qualifiers are typically integral approximations to the real relative display densities. This is a helpful simplification. For all of the complicated details, you might start with the material about lengths in the latest CSS specification.

Mobile phone screens are much smaller than what’s found on a modern desktops and laptops and connection speeds are likely to be slower, so we’d like to use a smaller and differently cropped image for the small screen scenario:

<img alt="robots" src="robots.jpg"
 srcset="robots-closeup.jpg 600w, robots-closeup-HD.jpg 600w 2x, 
 robots-HD.jpg 2x">

What we’re saying here is that if the viewport’s width is less than or equal to 600 then use robots-closeup.jpg or robots-closeup-HD – depending on the display’s pixel density, otherwise use robots-HD.jpg for double density displays, and use “robots.jpg” for everything else. To specify the maximum viewport size we use “w” and “h” to identify width and height qualifiers. For example to specify both: “robots-closeup.jpg 400w 600h”. Exactly what’s meant by the width and height qualifiers bears some explanation.



IMG srcset Viewport Size Qualifiers

An IMG srcset qualifier like “600w” means that the image is to be used if the viewport’s width, in CSS pixels, is less than 600. The viewport’s size is essentially the size of the visible part of the browser’s content window and it’s also defined in terms of CSS pixels. If you resize the browser window or zoom – and users zoom in and out a great deal on small displays – then the viewport’s size changes. When the user zooms in, the CSS pixel width and height of the viewport get smaller, even though the device pixel size of the browser’s content area does not. Similarly, when the user zooms out, the size of the viewport in terms of CSS pixels gets bigger. Changes in the size of the viewport cause the srcset to be reevaluated, and may cause a different image URL to be selected.

It’s significant that you cannot qualify the viewport’s size in terms of other units, like ems or inches, and you cannot qualify the viewport’s size in terms of the space it’s allocated after layout. This is to avoid creating any obstacles for the image preloader, which will go about its business long before the CSS cascade and layout have run to completion.

The Road Ahead

There are still some outstanding issues with the IMG srcset proposal and debates about how to make images “responsive” still flare up now and then. For example, specifying images based on the viewport size implies that authors need to predict the effect of the viewport’s size on their layout accurately enough to know how much space will be allocated for each image. And there’s still no solution for providing alternative images based on network connection bandwidth and latency.

The next step for this HTML feature is implementation in browsers, or “user agents” as they’re properly called. One can experiment with the syntax using a JavaScript implementation, like this one written by Boris Smus, and hopefully experimental browser versions will start to debut in the coming months. It’s quite possible that during this shakeout period, the srcset feature’s specification will evolve.

Here at Adobe’s Web Platform group we are happy to see that the debate about standard support for responsive images is making progress, maybe even drawing to a close. This seems like a good time for experimental browser implementations to bow, so that Web authors can take the feature out for a test drive and tool developers like Adobe can start adding support for this much needed feature.

Note Also: The Robots

I’d like to thank Richard Muller and for the robot photos.


  1. September 20, 2012 at 10:26 am, Mat Marquis said:

    Several solutions have been proposed and championed – notably a new picture element – and many expert Web authors and browser implementers weighed in via email, forums, blogs, on IRC, and probably in person. Finally in May, a new IMG tag attribute called “srcset” made its debut in the WhatWG HTML5 spec.

    The phrasing of this is a bit misleading. It’s worth noting that the picture element proposal was not supplanted by the introduction of the srcset attribute—rather, both are being developed in parallel. The picture specification is still being actively developed through the HTML WG. Several polyfills exist for the proposed markup pattern (notably, these avoid the prefetching issue described above), and thanks to the efforts of Responsive Images Community Group members several native implementations are in the works today.

    I’ll avoid rehashing the entire argument, but as I’ve explained at length elsewhere: the extended srcset syntax described above fulfills only a fraction of the use cases covered by picture, and the picture markup is overwhelmingly preferred by authors. I’ll admit I’m disappointed that Adobe has chosen not to support a community-led effort, but I would be interested in hearing more about the reasoning behind the preference for the extended srcset syntax.

    • September 20, 2012 at 11:34 am, hmuller said:

      Here’s why we’ve focused on the proposed IMG src attribute:

      – Extending the existing IMG element, rather than introducing a new one, seems prudent
      – The syntax for specifying alternatives is compact
      – The new attribute is similar to CSS image-set
      – The WhatWG HTML5 spec includes srcset
      – UA implementations should be relatively easy

      We acknowledge the strong differences of opinion about the best solution to the responsive images problem and we’ve been following the many discussion threads, including those led by the Responsive Images Community Group. As a tools vendor, Adobe is committed to supporting whatever solution sees wide deployment in user agents.

  2. September 20, 2012 at 12:15 pm, Mat Marquis said:

    I’m glad you brought up syntactical parity between a markup-based solution and the way similar problems are solved with CSS. The extended srcset actually deviates a great deal from the image-set syntax, introducing a number of new options and values apart from simply resolution switching—the purpose for which srcset was originally proposed—and deviates radically from the media query syntax already in wide use. The current picture proposal uses the srcset attribute as well, albeit in a way that matches very nearly one-to-one with images-set. The use of attributes bearing values nearly unchanged from image-set and leveraging the media queries with which authors are already comfortable will likely mean a much smoother transition for authors, similar syntax from our CSS to our HTML, and the full range of options afforded us by media queries rather than a siloed microsyntax that will (ideally) be developed in parallel with the media query specification. The picture proposal in no way precludes the use of srcset for simply specifying alternate resolution sources on an img tag.

    The terseness of the extended srcset syntax doesn’t read as a justification in and of itself—it should only be a factor so far as authorship is concerned. There is no inherent value (apart from a few bytes) to a solution that simply uses less characters if it’s more difficult for authors as a result, and the developer community has been highly vocal about their preference.

    In terms of ease of implementation, there has also been no shortage of outcry from UA representatives there—and it’s a factor in all this, for certain. However, in no way should implmentor preference trump a number of additional (and ever-expanding, through media queries) use cases that stand to have a greater benefit to the end user, and a syntax with a greater potential benefit to authors.

    In either case, I’m glad to hear that Adobe intends to support either solution—and to that end, either approach represents a long-overdue solution to a particularly tricky issue. I’d love to invite Adobe to review the progress on the picture proposal and offer up feedback on any potential or outstanding issues.

  3. September 21, 2012 at 10:39 am, JoeFlash said:

    Actually a 2x image is four times the size of a 1x image (both width and height are doubled). This can result in a web page with heavy use graphics and fully coded for 2x support being about four times the download size on mobiles than it would be for a standard desktop. This difference can seriously eat up mobile data plan bandwidths.

  4. September 24, 2012 at 10:04 am, Kevin L said:

    Interesting case for the img srcset attribute.

    That said, when it comes to content images–not pictures aimed for art direction or user interface elements (like logos, text-heavy icons, etc.)–simply doubling the resolution of the content image, reducing the quality to reduce the file size, and then using css or the img tag’s width & height) you have a retina-ready image without the hassle of doing the following technique or the technique.

    Anything else, this technique or the technique works rather well outside of RESS which is outside the scope of this article (and hope I’m not confusing people with the mention of it).

    I’m rather fascinated if both solutions can co-exist or one will be ultimately denied in favor of the other when it’s all said and done. and how long will the favored one be adopted (though that’s a rather pointless remark somewhat as the JavaScript supporting a particular method can be kept for a particular project)….

  5. September 26, 2012 at 12:58 am, Nimsrules said:

    An interesting read here. Had faced difficult times dealing with images while designing responsive websites. This should come to help.

  6. November 25, 2012 at 3:02 am, Responsive Web Design: Fresh Tools, Articles and Tutorials | Splashnology said:

    […] Responsive Images for HTML5 […]

  7. April 26, 2013 at 8:08 am, Brent Enright said:

    I am writing this this message in late April, 2013. I was searching for information on the (roughly) current status of responsive images (ideally photos in .jpg, .psd or .png format). The above article is the latest information I see published by Adobe. Has there been no progress in the last +- nine months to report?
    Thanks in advance for your (Adobe’s) input.