There are a bunch of techniques going around for dealing with responsive images lately. That is, solutions to help us serve the right image for the occasion (e.g. size of screen and bandwidth available). They all do things a bit differently. To keep track, Christopher Schmitt and I have created this spreadsheet of techniques.
The spreadsheet has the data, but let’s digest it through thinking about it through the lens of practical questions.
To choose which technique is right for you and your project these questions may help as a guide. Many of the questions may apply to your project, so you’ll have to sort out which techniques fit what scenarios and find the overlap.
Do I have legacy content?
Which really means… do I have legacy content that is impractical to update? For instance, I have thousands of pages of content on CSS-Tricks and a writing staff of one.

<img />
on the site, so I need a technique that will allow me to leave those alone.The only technique I know of that works with absolutely no markup changes is Adaptive Images. It works by routing requests for images through a PHP file which intelligently serves (and creates if need be) images of the appropriate size for the screen width.
Another question to ask yourself is if you care about legacy content. Perhaps the vast majority of traffic to your site is for newer content in which you can make markup changes and thus take advantage of other techniques. If that’s the case, read on to discover those other techniques.
If you have a small project, a brand new project, or a project with legacy content that you are able go back and update, you are also able to choose a technique which does require special markup, so also read on.
Do I care about special markup?
This is really a sub-question of the above. Many of the techniques require you to use special HTML. For example, HiSRC has you put higher resolution images as data-attributes:
<img src="200x100.png" data-1x="400x200.png" data-2x="800x400.png" />
I’d say this is a clean, valid, semantic technique, but it also means that you need these attributes on every <img />
on your site, which may not be possible on sites with loads of legacy content.
If you know that special markup (or specialized CSS) is not an option for you, really the only option is Adaptive Images. Even Sencha.IO requires prefixing the src attribute which may not be possible with legacy content.
Do I care about semantics?
Some responsive images techniques involve markup which isn’t strictly semantic. Ultimately, there is only one way an image can be semantic. That is if the src
of it points to a real image and it has alt
text describing that image. Brad Frost sums it up nicely:
@stowball Unfortunately its not that simple. A picture of a horse needs to be a picture of a horse or else its not a picture of a horse. :)
— Brad Frost (@brad_frost) April 5, 2012
In other words, if the technique requires at any point the src
of the image to be missing or link to a transparent GIF (or the like), that’s not semantic.
So why do some responsive images techniques do this? Because having an image with a src
that points to that image of a horse means that that image will start downloading as soon as that image gets parsed by the browser. There is no practical way to prevent this. Even if you super quickly swap out that src
with a more appropriate version, now you’re downloading two images instead of one which is a performance hit instead of a performance gain. You may decide that’s acceptable (e.g. “desktop” environments typically have more bandwidth). Usually if this technique is employed, the image in the src
is the smallest possible image.
If semantics is important to you, you should look at Adaptive Images (covered above) or HiSRC, a plugin by Christopher Schmitt which you can use with a semantic src
attribute.
A few of the techniques use
Do I care about validity?
Validity as in “Does it validate?” according to the W3C Markup Validation Service. Validation is a tool to help you find problems and write better markup. But just because something doesn’t validate doesn’t make it bad or wrong. If invalid code works wonderfully in all browsers, you nor anyone else should care.
If you do care about validity (perhaps a client irrationally requires it from you and is holding your paycheck randsom) then there are a few techniques that you can’t use. The picturefill technique, for instance, uses the <picture></picture>
element to work its magic. This may ultimately be standarized, but it isn’t yet, so it’s technically invalid syntax. It’s also required that <img />
elements have a src
attribute, so techniques that remove that to get around the double-image-request problem are invalid.
I’d recommend these techniques if validity is a requirement for you: Adaptive Images, HiSRC, or Responsive Enhance. All of which use simple, valid <img />
syntax that include a src
.
Do I care about art direction?
Some responsive images techniques serve different resolution versions of the exact same image. While that makes things easier (i.e. less work) it may not acceptable. Here’s a visual example:

src
. In the middle, a slightly larger image that could be used on (ahem) “tablets”. On the right, the largest of the images.(credit)These images are hand-crafted by a designer, cropped to retain meaning and impact. If you took the image on the right and just scaled it down, the people in the image would be very small and the feel of the image my be lost.
If this idea of art direction is important to your project, you’ll need a technique that will allow you to specify exactly which src to serve under which circumstances. This is picture perfect (GET IT?) for picturefill which allows you to be very specific about sources and what circumstances get what.
<picture>
<source src="small.jpg" />
<source src="medium.jpg" media="(min-width: 400px)" />
<source src="large.jpg" media="(min-width: 800px)" />
</picture>
JavaScript takes it from there.
Do I care about JavaScript?
Most of these responsive image techniques utilize JavaScript to work their magic. Some only a tiny bit to set a cookie, but JavaScript none the less. Some of them have you put an <img />
in a
What about JavaScript *library* dependency?
HiSRC and rwdImages are both jQuery dependent. If your project is using a different library, these probably aren’t for you. But hey, you could port it and open source that! If you aren’t using a library, well, you probably should be but let’s not get into that.
Do I care about Server Side Components?
Some of these techniques aren’t solely JavaScript dependent. Adaptive Images works it’s magic primarily through .htaccess and PHP. Well, .htaccess presupposes an Apache server. And, while of course we all know and love PHP (ahem), many websites run on technologies like Ruby or Python.
Responsive Images (the original Filament Group technique) also uses .htaccess. So if you’re using something like Nginx as web server, this is either out or you’ll have to port over the .htaccess component to Nginx’s similar-but-different syntax.
Do I care about bandwidth testing?
Testing the browser window width and making decisions on what image to serve based on that is pretty cool and fundamental to the concept of responsive images. But it’s really only half of what the decision of what image should be served should be based on. The other half is available bandwidth. If the user has a very fast internet connection speed, serving large images is OK. If the user has a very slow internet connection speed, they should get smaller images (regardless of screens size). Unfortunately native bandwidth media queries don’t exist.
Two of the current techniques do bandwidth testing as part of their decision making: Foresight.js and HiSRC (both are based on the technique in Foresight.js). It works by downloading a test file and measuring how long it took (configurable). The test itself is a slight performance hit, but theoretically the savings gained by serving images based on knowing the current bandwidth is a net (GET IT?) gain.
Do I care about relying on third parties?
Sencha.IO is a completely third-party way of handling responsive images. As far as I know, it works great and hasn’t been inflicted with any major downtime, but of course you always run that risk.
You might be thinking: Wow, the Sencha.IO technique is really cool but I worry about the third-party dependency. I wish I could run that on my own server. If you want to go down that road, there is the public WURFL database and this Server Side Responsive Images technique which puts that to work locally.
There are also third-party services like Device Atlas Cloud which does device detection for you. It’s also a third-party dependency for your app. No doubt their goal and focus is staying up and fast at all times, but you have to be very careful about who and what you rely on for your business.
A couple of other third party services: ReSRC.it, Responsive.io, Thumber.io
Is there a specific CMS with specific CMS powers involved?
Say your project is in WordPress. WordPress has a media uploader built in. When you upload an image with it, it can create multiple versions (scaling down) of that image for you. That’s pretty cool and powerful and you could/should take advantage of that.
This isn’t just a WordPress thing though. I’m sure the concepts at work here could be done (or made to be done) in any Content Management System.
Do I care about double-requests as long as the solution is mobile first?
Many of these solutions try to solve the the problem the best way possible: only making a single request for the right resource. If you are OK with linking up the smallest version of the file (so that request is made no matter what) and replacing it with larger images when needed, perhaps Source Shuffling would work for you. Do note that the library that uses now suggests using font-family
rather than content
to detect the media query changes.
Can I wait for the future?
The release of the “new iPad” (the third one, for longevity) is what sparked a lot of these techniques and conversations. Its high pixel density is great for vectors and big photos, but actually not great for things like small icons that need to be scaled up to be the correct size and can be blurry. But serving higher resolution icons means larger file sizes and slower websites. Hence, the need to only serve them in situations/environments that need them.
The world of web standards is aware of this problem. There is a whole group dedicated to talking about it. In time, they may solve it and then we can start using whatever way they come up with (assuming its awesome and better than what we have now).
It may be flipping out the src of images through CSS content like Nicolas Gallagher suggested. It might be the <picture></picture>
element. It might be a srclist attribute in HTML or src property in CSS. It might be a prefix.
It maybe sending browser information requests, like in Client-Hints.
More resources
- Jason Grigsby has an epic three-part series on responsive images starting here.
- Christopher Schmitt’s slides on a whole talk about responsive images.
- Mat Marquis on Responsive Images: How they Almost Worked and What We Need
But what about using the height/width auto trick? It’s what I’m using by default now for responsive layouts.
#contentwrapper img {
max-width:600px;
height:auto;
}
That works to resize the image, however the point of this article is to address serving preformatted or automatically formatted images that are smaller sized – i.e. MB and KB, not height and width.
By serving up the optimized images, you’re using less bandwidth in cases where it might be appropriate, like on a smaller screen that isn’t going to properly display a huge-resolution image, or will take up less bandwidth for those concerned with their user’s data limits on mobile devices.
Great article, hopefully there will be standard solution in the future especially seeing that responsive web design is becoming more and more popular. I haven’t had the time to really get into personally (and when I start to look into it I get turned off by some of the issues like this) but in combination of this article and lack of plans this weekend I am thinking I might just have to dive in and play around with it some! Thanks!
My personal favorite is the tag solution – just seems to be the most straightforward and easy to implement. One day…
*Picture tag – wrote it in code doi.
Great stuff – I was until now unfamiliar with Adaptive Images, but have been using a similar technique using either phpThumb or SLIR (Smart Lencioni Image Resizer).
Since my default CMS is MODX, using phpThumb is my main technique since it’s built into MODX, and it works quite nicely, but Adaptive Images looks nice and streamlined and since it’s based on php, I know it’ll work well with MODX. Kinda curious to try it out now!
In general the most I care about is art direction. Because that’s what the user cares about.
They don’t care about semantics, they care about if it’s valid, they don’t care if it comes from a 3rd party and so on.. but they care if the people in the image are so small that they don’t recognize them.
ps. not saying you as a developer shouldn’t care, but users first.
Agreed – this is important. Your point is a bit vague though.
I think a balance of all aspects (art direction, efficient code, semantic markup) is more important than focusing solely on user experience above all else. It’s very important to note that user experience is not only the visual appeal of your site, but also in things like load times and responsiveness.
Yeah, that´s true. But they care about performance as well…
User experience should also include all users, including the visually impaired who rely on screen readers. This is the main reason I would personally put an emphasis on semantics.
The longer I do this web dev thing the more I realize that it doesn’t really matter how pretty a site is if it doesn’t work for the user.
Full disclosure – I have a son who is lost most of his usable vision at the age of 15, he is 19 now. While semantics mattered to me before it is a primary objective in my work now.
The vision impaired community is a lot bigger than you realize.
Trisha
5/21/2012
Trisha,
I agree 110%. Some devs tend to forget that they’re not only designing for different devices and screen sizes, but also for different PEOPLE (this one being the largest single variable ). Successful design marries functionality with aesthetics, and gives each of them equal importance (for a good example of this, see Apple’s industrial design). If you ignore functionality (or give it less importance), then you’re branching over into the realm of fine art instead of design (and last I checked, fine art is not readily accessible to everyone – you need to understand it before you can access it. Not too intuitive an approach for UI design). The accessibility thing is very personal for me as well, as I have three special needs kids who benefit from it every day.
Good developers care about Accessibility, And this incorporates both semantics and validity.
It should be Users with Disabilites first!
Another solution worth mentioning:
http://responsejs.com/
Too bad you didn’t mention Riloadr in your analysis: https://github.com/tubalmartin/riloadr
On a recent project we started using HiSRC for responsive images but later on a friend recommended us to try Riloadr. After a long testing session, we switched to Riloadr due to its flexibility.
It’s the best tool we’ve found to date.
“srcset” has been left out of this, which seems like the smartest “solution” we’ve seen yet.
Business rules / requirements, infrastructure updates / changes will cripple the implementation of “picture”, and the cost of doing business in a Content Heavy environment with this new tag will preclude many businesses to not move forward with this markup — and by Content Heavy I mean *not* blogs, think more FoodNetwork or HGTV — Heavy Content.
Ultimately whatever solution is adopted *needs* browser and server support, whether heavy or light. Markup changes/updates are just one piece of the puzzle and should *not* be championed solely by front-end devs. FE devs can suggest the best route forward in terms of markup, but the heavy lifting needs to get removed from the front-end.
Great article! I missed one section about performance. What if I care most about performance and don’t care about semantics or JavaScript. Which solution should I use?
Probably something local (non third party), that doesn’t download duplicates, dont use jQuery or any library, triggers instantly (doesnt wait for onload),… any recomendations?
Riloadr will make you smile I guess!
Re: image content – there are several libraries concerning ‘image saliency’ that might help a machine to decide where the points of interest are in an image, and crop accordingly.
Just thought I’d mention this Tweet referring to the WHATWG efforts to create markup standards that would (one day) solve all our responsive image issues:
“Urgent! RT @wilto If you care about responsive images, we need your input–and the WHATWG needs to hear your voice. cog.gd/3tt”
*its
Great article, definitely gave me plenty to think about.
I prefer to avoid special markup because in my experience it only confuses the browsers and older browsers usually fail. Yes IE 8 and older I am talking about you…
Btw this blogs design is very nice
One solution not yet mentioned, is Molt. Like HiSRC it uses data attribute to define the real sources, but I like its minimal syntax. Eg.
Awesome article Chris. I’m managing the build out of a new social web app as well as building out a new responsive framework for my company to use on projects going forward. Something we’re focusing very heavily on is performance in terms of speed and UX. Responsive/Adaptive images are a big point of contention right now so your spreadsheet and article are great timing for me! I’m a huge fan of your video screencasts and think it would be really cool to see your favorite examples in real time.
Again, great article!
Whilst utterly useless for images, I’ve been using SVG for icons and logos. For the older browsers I quickly swap in PNGs, there is a performance hit, but usually only on desktop environments.
For it’s apparent ease of use, I’m surprised more people haven’t picked up on SVG for their icons etc.
Awesome article Chris. thank you
Great info! With the increase in demand and growth of tablet and mobile devices there has been an explosion of Responsive website demands – the more tools the better!
Thanks for the great overview Chris.
The WHATWG seems to have put out their own proposal in the form of an
img
set
attribute.Most developers, including myself, feel strongly this is not an improvement over e.g. a new
picture
element.Also, there’s an interesting discussion going on in the W3C Responsive Images Community Group about a different approach.
Basically it’s about adding a (couple of)
meta
elements with media queries, declaring a ‘variable’ to be used in the HTML (and CSS/JS?)E.g:
This would then allow the following (using an URI-template)
And, potentially in CSS:
@media (case: breakpoint1) { ... }
Anyway, I think it’s an interesting approach that addresses a couple of issues. Have a look at the article by @MattWilcox and share your thoughts.
Great post bro. Maybe it’s not about a topic but, for rewriting images’ titles , caring SEO, in wordpress there are some plugins i use like ‘SEO Friendly Images’. This article is sufficient enough , composing many topics. Waiting for your next post ;-)
Chris, this was my idea. It makes replacing img tags a breeze, because you can just do a simple search and replace, either in your text editor or via SQL – without affecting the source. It’s probably bunk, but it was just an idea I had to refine the picture tag idea. Would love your feedback.
http://michaelgunner.co.uk/proposed-responsive-images-syntax/
IMHO Matt Wilcox’s Adaptive Images is my recommendation if your using PHP.
– No need to manually create multiple versions of your image,
– Can standalone, often no changes frontend markup or serverside
– Can still function without Javascript
Great post! It’s best to start the practice now, as retina displays are here to stay. I have hope CSS will develop along with the technology to make designing responsive sites easier.
following up the CSS3 is the best way to bring responsiveness.. and even the HTML ways works fine…
I love the picture tag – I didn’t know about this before.
I don’t know how practical it is though, and whether many developers/designers are willing to create several copies for each image to serve it. If done on the fly by the CMS, then it’s an ideal solution.
How does rwdImages compare to Adaptive Images?
Great post. Really serving up better images for so many different type and capable devices are going hard these days.
But I would really love a solution for this like CSS Media Query as David Hund said.
On replying this question “Can I wait for the future?” — I make myself convinced to an answer “NO”!
Because we have already started working and user’s are already getting their device friendly browsing experiences with Responsive Web. So we should get start with what we have now and gradually upgrade ourself before we fix our mind with one dedicated solution.
I am using Foresight.js and it’s quite better.
With the increase in demand for responsive websites, the more tips the better. Great post, I learned something new today. Looking forward to the next post.
Hi,
We are using responsive images at globo.com.
We have four different versions for each image:
a) A low quality (between 4-5x smaller than original) to serve in the page mark-up.
b) A ‘desktop’ full quality image
c) A ‘tablet’ full quality image (smartly cropped using facial recognition)
d) A ‘smartphone’ full quality image (smartly cropped using facial recognition)
We put each URL (other than low quality) in the markup as data-x-url:
The process we use is that we monitor the page scroll and change the low quality image to the high quality one for the given device only when the user “approaches” the image.
It has worked quite well for us and we are very happy with the results. Our website handles almost 2bi page views / mo with 30-40 responsive images at any given time.
The tool we use for handling the sampling and cropping of the images was built by us and has been released as open source (https://github.com/globocom/thumbor/wiki).
Cheers,
Bernardo Heynemann
Tech Lead @ globo.com
You could possibly use a combination of media queries, adjusting the width and then using clip to highlight a specific area for an img. Although this may be more of a pain in the ass than it is helpful due to the fact clip only works when you position absolutely and you have to calc the top, left, right, and bottom offsets.
Just a thought though!
Here’s a jQuery plugin that ajax-loads an entire HTML fragment into the page, given current window width (and pixel density). It can be used to tell the server to supply appropriately sized image src URLs etc. It’s a fork of Github’s Pjax loader. It does not rely on User Agent or cookies – just window width.
http://stephanfowler.github.com/responsive-content/
Correction to that url:
http://responsivecontent.net/
I currently use very low quality images in the markup, and then use javascript to swap them with a full quality image after the page has finished loading. This makes the page load fast, and it serves the highest quality image eventually.
This is a great article that helps to highlight why making a solution for responsive images is hard, and why there may never be “one to rule them all.” I do think/hope that agreement among standards and browser folks can solve most use cases.
I also wanted to point out an inaccuracy. Scott Jehl’s picturefill solution does not require the element. I uses spans so it is actually standards compliant. Of course you are right in that it does require JavaScript, albeit with an HTML fallback that will show if no JS is available.
Very nice article, another interesting article which I would like you guys to read is http://mobile.smashingmagazine.com/2013/07/08/choosing-a-responsive-image-solution/ You can have a more clear sense about some popular responsive solutions.
My question is : I heard before that background image in CSS media query reduce performance, because all images in different sizes will be downloaded from server and some unnecessary requests would be sent. Is that true?
Pixtulate is a third party responsive image service capable of both scaling and cropping responsive images, including using focal points for art direction purposes. It allows you to serve responsive image, create thumbnails on demand and intelligently crop hero images.
This list is great, but it leaves out mention of SVG clowncar. In my testing, SVG clowncar is more up front work to develop your breakpoints, but it has none of the side effects of javascript or experimental markup based solutions.
I’ve been using it on a production website for 5 months and have run across only two problems:
* Users can’t right click and view image src
* You have to add a link element with proper schema.org markup for search engines
Another technique that arrived after the publication of this article is Slimmage. It intentionally avoids art direction – but if you don’t need that, it provides everything else. Speed, CSS media query support, no duplicate network requests, and full spectrum browser compatibility.
It requires a server-side component (most frequently, it’s used with ImageResizer), but it can work with any RIAPI-compliant backend.
I wanted something simple and to the point, so here is my take on the problem with JavaScript.
https://github.com/smasala/responsive-images-js
Picturefill 2.0 is out and I think their solution with PICTURE element and multiple SRC attributes is the cleanest as of yet.