3 Types Of Solutions To Work With Responsive Images

One of the big 3 requirements for responsive design is flexible images and media. On the surface it seems like an easy thing to do. You remove width and height attributes on images, set their max-width to 100% and call it a day. Beneath the surface there’s a lot more we need to consider.

James Pearce showing off The Boston Globe redesign

The Problem with Images in a Responsive World

When the Filament Group was redeveloping the Boston Globe website last year they too added max-width to keep images flexibly inside their containers. The problem though, is in order to do that you need to create images as large as they can possibly be. You end up with an image with the maximum dimensions and maximum file size.

Unfortunately for all cases except when the maximum image is needed, that’s wasteful. Smartphones and tablets connecting over a cell network don’t need an image larger than they can display. It just easts bandwidth.

Even if bandwidth weren’t an issue you still have to consider if the same image works at very different sizes. What’s communicated in the details of a 1000px image might be lost when that image is 300px. Better than resizing, might be to crop the image or use an entirely different one in its place.

And let’s not forget about high resolution displays. With Apple introducing retina display across more devices we want our images to contain more pixels. Other devices will likely follow Apple’s high-res lead, though perhaps with different pixel densities.

We can’t simply preload all the different images we might use, since it defeats the whole point. We’re trying to reduce bandwidth needs, not increase them.

We need a greater ability to serve device and context appropriate images and media.

Three paths in the park meeting

3 Paths to Solution

There are several paths being considered or explored to solve these problems. Chris Coyier summed them up nicely in his post on responsive images. We can:

  • create a new (html) element
  • create a new image format
  • fix the problem with other technologies

Let’s take a look at the solutions in each path.

Create a New Element (or Attribute)

This is already in the works, though how it’s proceeded has been an issue in itself. Without getting into the controversy there are basically two proposals, one coming from the web development industry, and the other coming from the browser makers.

The proposal from the develop side creates a new picture element similar to the existing video element. Inside is another element, source, along with the usual img element and it should be relatively easy to understand what’s going on if you look at the code below.

{code type=html} image description {/code}

The img element is the default so what’s in its src gets displayed by default. Above it the two source elements point to different images that would be displayed based on the different media queries. If it comes across as easy to use, that’s because it is. It’s a developer friendly solution.

Scott Jehl created a polyfill for the picture element so you can use it now.

Code for picture element and  srcset attribute

Browser makers are offering another proposal that instead adds a new srcset attribute to the img tag. It’s probably not as intuitive to understand, though it’s similar in how it functions.

{code type=html}


Let’s look at the first value in the srcset attribute above.

{code type=html}
path-to-another-image.jpg 600w 200h 2x

  • path-to-another-image.jpg should be self explanatory. It’s the image we’ll use when the following conditions are met.
  • 600w and 200h are equivalent to min width and height media queries.
  • 2x represents the pixel density. 2x is twice the normal density.

So here when the browser can handle a 2x image and is at least 600px wide and 200px wide we’ll serve it the image specified.

This solution works well from a browser maker’s viewpoint. It can better algorithmically determine device capabilities around pixel density.

Again I’ll stay clear of the controversy, except to say each syntax has valid reasoning for why it should be the standard. If you want to know more about the controversy, click some of the links in this section. They’ll lead you pretty quickly to it.

As someone who develops websites I like the syntax of the picture element, however I think given the backing we’re more likely to see something like the srcset syntax. The discussion is still ongoing and most seems open to incorporate the best of both.

I recently listened to a couple of podcasts discussing all of the above.

Camera and film canisters

A New Image Format

This one should be simpler to explain. Christopher Schmitt is calling for a new responsive image format. The new format would basically be a container for several different sized versions of itself within. A 100k file might have a 75k version, a 20k version, and a 5k version of the same image inside.

In a way it would work like .mp3 files that store both song and meta information about the song. Here though instead of meta information the new format would store different variations of the image.

A standard set of rules would determine which of the inside images is the one that gets served to the device. Where the code is concerned this is as simple as it gets. Nothing changes, other than using a new image extension.

The downside is we’d be giving up some control. The new image format itself would determine the rules for which version gets delivered and when. It also wouldn’t be backwards compatible to browsers that don’t understand the new format.

Technology: A Gift that keeps on giving

Other Technologies

Both of the options above, while relatively simple, aren’t here yet. If you want to serve the most appropriate image to each device right now, you’re going to have to use one of the other methods. There are quite a few of them. Too many to try to describe them all in one section of a post.

Many follow the lead of the Filament Group. Their responsive images method with the Boston Globe took the following approach.

  • Markup — defaults to the image for mobile devices
  • Javascript — determines the viewport size, stores the information in a cookie that’s passed to the server, and changes the img src for the appropriate image.
  • Server — intercepts the initial image request, reads the cookie, and if not a mobile device redirects the image to a 1×1 spacer.gif, until Javascript could swap to the appropriate image

It didn’t quite work as well as hoped, though it pointed the way and gave everyone something to build on.

Most of the methods that have come after generally share similar characteristics. They serve the mobile image by default and then attempt to detect device characteristics before serving the most appropriate image.

Chris Coyier and Christopher Schmitt created a spreadsheet with different techniques along with information to help you decide which is best for your project. Chris also wrote a post based on the spreadsheet to answer the question, which responsive images solution should you use?

I’ll mention a few of the methods below with a quick word about each so you can get a feel for how they work. You should really check Chris’ post and the spreadsheet for the details on these and many other methods.

Foresight.js uses Javascript to test if the device is capable of displaying high-resolution images before the image is requested from the server. It also checks the speed of the network connection the device is using.

Depending on what it finds, it then requests the appropriate image for display.

Images redux uses a blank 1×1 GIF (converted to base64). It sets the background of this .gif to whatever image needs to be served and also sets the background-size property to the value contain.

Because the image you want to display is set with css, it can be changed via media queries.

Image of President Obama greeting troops cropped for 3 sizes

Image above via CSS Tricks

Adaptive images was inspired by the original work on the Filament Group did when redesigning the Boston Globe site. It requires Apache 2, PHP 5.x, and GD lib, though these are all fairly common.

The technique begins by setting screen resolution in a cookie and then reading that to determine which image to use. If Javascript is off and no cookie has been set, it checks the user agent string. If it finds “mobile,” it sends the lowest resolution defined in $resolutions. Otherwise it assumes you’re on a large device and delivers the highest resolution image.

HiSRC is a jQuery plugin that detects network speed and resolution capabilities. By default the smallest image is served, but if HiSRC detects the device more capable it serves a different image.

Conditionally Loading Content is a post from Jeremy Keith, where he described how he was serving different images to different devices. It’s a custom solution where Jeremy is testing for the width of the viewport. Conditional CSS is a follow up post presenting solutions from others that improved the initial solution.

Cover from Ehtan Marcotte's Responsive Web Design book


The first step in making your images responsive is to make them flexible. Remove width and height attributes and setting their max-width to 100%. It doesn’t solve all problems though. The main one it leaves is that we’re required to create a single large image that isn’t best to serve to all devices.

In time a couple of things will happen. Bandwidth will increase to the point where this is mostly a non-issue (at least when compared to the next bandwidth issue) and we’ll have new html syntax to tell browsers which image to serve. Perhaps we’ll also get a new image format that can deal with the issue for us.

At the moment we have to choose from a variety of techniques that do similar things. They serve a mobile version of the image and test to see if the device being used can handle a bigger image. If so the script replaces the mobile image with the bigger one.

As hard as it might be to believe, there’s still more to say in regards to images and responsive design. I’ll save that talk for next time where we’ll look at vector images along with a few things that didn’t fit into this post.

I’ll leave you today with a short series of posts about responsive images from Jason Grigsby.

« »

Download a free sample from my book, Design Fundamentals.


    • Thank you Mat. I’m pretty sure a lot of what’s in this post comes from things I’ve heard you say recently. I appreciate all your work on this.

      I thought I saw several versions of Scott’s original Picturefill on Github. I probably should have linked to all of them, but the post had so many links as it is. My bad.

  1. Thanks Steven. Solutions for responsive images summed up really well.

    BTW, would you like to share your own preference. What method(s) do you use normally?

    • Thanks Nomi.

      So far it hasn’t been a big issue for me, given the specific sites I’ve worked on and my client’s needs. I’m looking forward to either picture, srcset, or some combination of both being more readily available.

      I don’t have enough experience with all the “other” methods to suggest one. I think they all work and for the most part work in similar ways. You probably want to keep up with the latest versions of each method and I would highly recommend checking Chris Coyier’s post and accompanying spreadsheet. It has some great suggestions as to which method to choose when.

  2. Adaptive Images only checks User-Agent as a fallback when JavaScript is off. When it’s on, a one-liner sets a cookie with screen width.

  3. Good Article. You mentioned in your summary ‘Remove width and height attributes and setting their max-width to 100%’ — You shouldn’t have to remove the attributes from the HTML (if anything it’s a bad thing), just add the CSS ‘height: auto;’ (along with the max-width).

    I wrote a similar article about the matter a while back, http://bit.ly/Maaw3b

    Good Job on the whole.

  4. Thanks Edd. Nice article on your end too. I’ll have to check on leaving the width and height in the html. I was under the impression that leaving them in would override what’s in the css, but now that I think about it, I’ve never tested it.

    What’s the rationale behind it being bad to leave them out? As far as I know browsers can still determine the native size of the image?

  5. Good question as to why, I forgot and had to Google it – there’s a good question on StackOverflow about it, http://bit.ly/MXbpqO

    By including a correct width and height attribute in HTML you are allowing the browser to load the page quicker because it doesn’t have to “…reflow and repaint once the images are downloaded”. Just for speed purposes then 🙂

  6. Thanks Edd. I used to include the width and height for that very reason. I started leaving it out when I started developing more flexibly. If you set max-width on an image to allow it to scale, but have the absolute measurement set in the html, then the height doesn’t’ seem to adjust to maintain aspect ratio by default.

    I’m playing around with it some though and it looks like if you specify height: auto on the image then it still scales to maintain aspect ratio even when the dimensions are set. I’ll play around with it more to make sure, but that’s how it seems to be working in some early and quick tests.

Leave a Reply

Your email address will not be published. Required fields are marked *