Why Responsive Images Is So Hard

Avatar of Chris Coyier
Chris Coyier on (Updated on )

DigitalOcean provides cloud products for every stage of your journey. Get started with $200 in free credit!

Perhaps you’ve been keeping up on the responsive images #hotdrama? If you have no idea what “responsive images” means, it means serving different images under different circumstances. How to do that and what those circumstances are vary widely.

If you aren’t caught up, here’s some linkage. Bruce Lawson did an end of the year report. This provides a nice history of the work behind trying to standardize a solution. Mat Marquis wrote up a succinct summary of where all the major browser vendors are at (no consensus). Tim Kadlec has a nice summary of the situation. Dave Rupert has been talking about it as well.

An important thing to understand here: all of this talk is focused around images in the HTML. Content images.

This problem is largely solved in CSS. If the image being added to the page doesn’t need to be in the markup, you can use media queries in CSS to handle the conditions and change the image accordingly.

/* Look ma, responsive images */

body {
  background: url(mountains-small.jpg);
@media (min-width: 500px) {
  body {
    background: url(mountains-medium.jpg);
@media (min-width: 800px) {
  body {
    background: url(mountains-large.jpg);

Of course, sometimes images do need to be in the markup. That’s what <picture> and srcset and srcN are all trying to solve. It’s a tough job. The solutions needs to:

  • Deliver only one final src
  • Be semantic
  • Be accessible
  • Be backwards-compatible
  • Accomodate art-direction
  • Accomodate all the conditions we deem important
  • Accomodate future conditions we aren’t even thinking about yet
  • Work independently of any other language/technology
  • Be agreeable to authors AND standards people AND browser vendor people

Why is it so hard for everyone to agree? Nobody involved is evil. Nobody is is sitting in a dark castle tower laughing maniacally. Nobody is intentionally delaying a solution. At least as far as I know.

I suspect the problem is the browser vendor people are trying to:

  1. Make educated guesses as to the difficultly of implementation.
  2. Make educated guesses on what the future would be like with the particular implementations in place.

While authors:

  1. Are pretty sure we know what we need.
  2. Are concerned about our needs on our projects and, while we care about the web as a whole, have less perspective on that.

And standards people need to:

  1. Make sure nothing gets broken.
  2. Cover as many needs as possible.
  3. Also make educated guesses on what the future would be like with the particular implementations in place.

And after they have make all those guesses, they argue for/against the solutions presented. It makes sense that there is disagreement, because it is hard to back up a guess with data. A lot of people are just shooting from the hip. Mix in egos and politics and its amazing it has even gotten this far. I’m rather astounded we have web standards at all (knock on wood).

But I digress. What if you need responsive images in your markup right smurfing now? Because, let’s say, theoretically, that there is a crapload of devices loading webpages out there with a huge array of screen sizes and screen densities and screen colors and internet speeds and such. Oh wait.

Even if you’re like, screw standards, I just want to do whatever I have to do right now to solve this. These are the options:

  • Skip the src attribute, let JavaScript figure out what the conditions are, inject src. 90% of “new” responsive images solutions I see are this in some flavor1.
  • Get the server involved. Have a cookie (or the like) available with conditions data in it. Intercept the HTTP Request for the img src, check the conditions data, serve up an appropriate image right from the server.

There are existing solutions for both of those techniques, with slightly different ways of going about it. I guide you to those in this article.

And remember a markup-based solution possibly isn’t the only place to handle this. There are other ideas floating around that take completely different roads:

  • Perhaps a new image format can help with this inherently.
  • Perhaps servers could help us somehow automatically.
  • Perhaps a new protocol could help.
  • Perhaps we should be able to control browsers prefetching behavior directly.

All the #hotdrama we’re having with just the HTML solutions would almost surely happen when we start down those roads.

So yeah, hard.

1 If you’re going to make another one of these, I humbly request that you make it like a polyfill and use a syntax that already has some momentum.