Responsive Image Solutions

Responsive ImagesImages on mobile devices have become a hot button issue as of late. Aside from the recent surge in responsive design compatibility, the reason for this, according to Estelle Weyl of Smashing Magazine is because, “no one likes any of the solutions thus far.“

Heated debates are happening right now on W3C (World Wide Web Consortium) forums and new articles on the subject pop up online almost every day. Many websites with mobile counterparts are serving up images that are not always the appropriate choice for all devices. The request is a simple one – provide users with one appropriate image for their device and resolution. This needs to be done without wasting time and bandwidth and should, above all things, be easy to implement and understand for developers. Instead, it is one big frustration headache for us and for users alike. We really don’t like jumping through a lot of hoops so please don’t make us.

“Responsive images have been a tough topic for years now, as there have typically been more than one ‘hack-around’ way to make your images responsive.” – Dain Miller, Web Designer Depot

Hacks are never a good idea.  While they are sometimes a necessary evil, it is always good to try to fix something the old fashioned way before using a hack.  But up until recently, these less-than-reputable techniques were needed to make images responsive.

A Code to Cope

Because there has been a lack of supported methods, many sites use a one-size-fits-all approach – serving up an image at its largest size. This is usually fine for desktop versions. But, for mobile devices with slower internet connections it is not ideal.

Typically, in most cases this little line of code works like a charm:

img {
max-width: 100%;

Once this is in your style sheet it works like this: if the container holding the image becomes narrower than the image itself, the image will scale down accordingly to match its container’s width.  Also, this ensures that an image will not scale larger than its actual size. Doing so would cause the image to appear over-blown and pixelated, significantly reducing its quality.


Newer high-resolution displays, like the Retina Display on Apple’s iPhone and MacBook pro can make this a little bit tricky. Retina Displays basically have double the pixel density of standard screens, so developers often combat this by making the image much larger than it needs to be and scaling it down. Sending high resolution images, however, wastes bandwidth and memory. Conversely, using low-resolution images looks less crisp on high resolution displays.

Need a better example? Think of it this way: Say you have a very large image; it looks beautiful on your high-resolution desktop. Like the good developer that you are, you pull out your iPhone to check the mobile compatibility of your site. While the image is still visible, much of the detail and crispness is lost.

Some developers put all image variations needed on one page. Using CSS classes and media queries, the images would be hidden and shown based on screen width. The problem with this is browsers are too quick. If an image is on a page it is going to be pre-loaded by the browser, regardless of whether or not the image is visible. Users still have to wait for all the image’s variants to download.

Other Solutions

Thankfully there are several solutions to remedy the issue; however as previously stated, there is a war waging in the web development community about which is the one technique to rule them all, as well as a great deal of confusion.

Luckily, the web development and design community has no shortage of creative, smart people who have been working to solve these problems. Of course, the flip side of that coin is that it’s easy to get overwhelmed by the sheer number of responsive image solutions out there. How do you decide which is best for you? Sherri Alexander – Smashing Magazine

The W3C has not declared any solution to be the best one. This is because many are neither semantic nor easy to use. Since the W3C has not put its seal of approval on any one method, most are considered to be “use at your own risk.” Many are currently being reviewed and tested by the W3C, but that does not mean they are free of bugs and potential, harmful issues.

Some solutions rely heavily on JavaScript and jQuery. This is tricky not only because some mobile carriers interfere with JavaScript, but any number of things can break it. Plus, if you are not using the jQuery library on your site, these options will not work. Surprisingly, a large number of website users disable JavaScript in the browser by default. Furthermore, many of the techniques are messy and complicated.

Regardless of the success rate (or lack thereof) of the current solutions, they may not be supported by all browsers. Not only is this frustrating and disconcerting for developers, but it creates a series of accessibility problems.

Adaptive Images

One of the best options I’ve discovered so far is Adaptive ImagesThis allows developers to upload the different images, implement a PHP file, a line of JavaScript and a little backend code. The goals of this method were simple, according to its creator, Matthew Wilcox:

  • Has to be easy to set up and use.
  • Must be as low-maintenance as possible.
  • Has to work with existing content, no markup edits or custom CSS needed.
  • Must allow for multiple versions.
  • Must work with design breakpoints and not device breakpoints.
  • Must be easily replaced when a superior solution arrives.

Source: Dain Miller – Web Designer Depot

The goals rely heavily on the assumption that a site is already using the highest resolution image available. Thankfully, many designers and developers do this already.

To put the process in simple terms…

The JavaScript detects the largest screen dimensions of a device and stores this in a cookie. The back-end code then sends different requests to the PHP file, which then tells the server which image to load.

Sure, it relies on 3rd party scripts (which unfortunately, may cause a whole slew of problems with other scripts) but out of all the solutions I’ve discovered, it is the most logical and easy to understand.

This solution also is a good one for large sites with legacy content.  You do not have to change any markup and it plays nicely with almost any CMS and flat HTML pages. But there is one caveat, because it uses Apache (a web server software program) and PHP, Adaptive images may not work on all website platforms.


The part that I like most about Adaptive Images is that you do not have to change any markup unlike another popular method, HiSRC.

HiSRC requires a developer to add a few extra attributes to a traditional image tag. These extra attributes would have different image sources for different resolutions.

<img src="200x100.png" data-1x="400x200.png" data-2x="800x400.png" />

It works by loading a mobile first version of the image and then it checks for a high-speed Internet connection and screen resolution. If this is the case, it loads the sequential, larger images.

“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.” —Chris Coyier: CSS Tricks

This would be a fine solution for a brand new site or for new sites moving forward. But at our web development agency, we have quite a few older sites with mountains of legacy content.

HiSRC also forces the browser to download two or three images at once. An image starts downloading as soon as it is parsed by the browser. Coyier puts it best: “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.”


Most developers care if their sites validate. The W3C Markup Validation Service defines validation as a tool to help you isolate and diagnose problems and write better markup.  Many things cause sites not to validate, such as WordPress plugins and certain tracking codes, but on the whole developers should—and do—strive to write clean code.

But if you don’t care about validation and the previous two responsive image solutions are not for you, there’s always Picturefill.  Picturefill does not, at this time, pass the W3C’s validation service because it uses the experimental and fairly new <picture> element – one which is not standardized yet, so technically it is not valid syntax.

Picturefill is also a little bit cumbersome:

<picture alt="Image Description">
  <!-- smallest size first - no @media qualifier -->
  <source src="image-source1.jpg">
  <!-- medium size - send to viewport widths 400px wide and up -->
  <source src="image-source2.jpg" media="(min-width: 400px)">
  <!-- large size - send to viewport widths 800px wide and up -->
  <source src="image-source3.jpg" media="(min-width: 800px)">
  <!-- extra large size - send to viewport widths 1000px wide and up -->
  <source src="image-source4.jpg" media="(min-width: 1000px)">
  <!-- extra large size - send to viewport widths 1300px wide and up -->
  <source src="image-source5.jpg" media="(min-width: 1200px)">
  <!-- Fallback content for non-JS or non-media-query-supporting browsers. Same img src as the initial, unqualified source element. -->
  <noscript><img src="image-source1.jpg" alt="Image Description"></noscript>

This is some pretty scary looking code if you ask me. Technically, it is seen by the browser as one image, and by using a little bit of JavaScript magic, the correct image is loaded. Theoretically, it is a good idea since it provides images for various mobile breakpoints. As previously stated, this method is not standard and the W3C does not support this yet. Src Src is a 3rd party solution cloud platform for images. The nice part is that no configuration is needed on your server, but since you are depending on an external resource, down-time and unexpected problems beyond your control are always possible.

Regardless, works like this:

<img src="" alt="My large image" />

Prefix any image with and resizes it to fit the width of a user’s device. can also be customized to return specific measurements based on screen orientation, widths based on percentage, and other kinds of calculations. is a great solution for those who are unfamiliar with jQuery and JavaScript or do not want to deal with a server side option. But as I mentioned before, it is a 3rd party solution so there is some risk involved.

The SVG Clown Car Technique

All of these methods have their own unique advantages and disadvantages. But none are the so-called “Holy Grail” option according to Weyl. She writes, “What we really want to do is find the holy grail: the one solution that sends the image with the most appropriate size and resolution based on the browser and device making the request that can also be made accessible.”

According to Weyl, the humorously named “Clown Car” technique  is the mythical chalice we’ve all been searching for. It is called this because it involves including (or stuffing) many images (clowns) into a single image file (car).

Although Weyl admits the technique is not perfect yet, it has the potential to be. What makes this technique so interesting is, unlike Picturefill, you’re downloading a single file. The only weird part is rather than use a JPG or PNG, this method uses an SVG. SVG stands for Scalable Vector Graphics and basically means it is a file with several smaller file components in it.

The clown car technique uses media queries to tell the browser which image to load based on screen width. All the images are stored in one directory and only called upon when it is time for their solo act.

It sounds good on paper, but it has drawbacks:

When using an SVG file, all the image components are downloaded at the same time. The solution to that is to use background images instead. While this is not that uncommon since background images have been used for sprites and various buttons, it is an odd solution for every image file.

All browsers support SVG media queries and SVG as content images, but the support is not identical cross-browser due to security policies. This is because SVG files always contain several smaller components and sometimes are malicious in nature. Many browsers have policies in place to prevent SVG files from importing malware. So while it is “supported,” browsers like FireFox and Safari, prevent SVG files from pulling in external images.

Weyl writes, “Firefox supports SVG and supports SVG as background image, but blocks the importing of external raster images due to their content security policy (CSP).”

Furthermore, the images are blocked even if the images are on the same domain. This makes a lot of sense; you never want files to be pulling in untrustworthy content.

The <object> Tag

Because of this, Weyl suggests using the <object> tag instead. This tag is often seen in video and flash embed codes, but is globally supported by all browsers. However, this technique only works if the browser supports SVG. (Therefore IE8 and below are out of luck.) But with a little tweaking and magic, the method using the <object> tag works surprisingly well.

However when using the <object> tag, any browser with add-blocking software can view it as a blockable item and be invisible by default. Also, unlike normal images, you cannot right-click (or CTRL click on a Mac) to download the file. Worst of all, <object> tags do not support the alt attribute, which not only makes images more accessible but is a popular tool for SEO.

In my opinion, this seems like a bleeding edge solution, albeit a very inventive and interesting one. At our digital marketing agency, we have no plans to try any of these methods as of right now. But it is something of which developers should be aware. Developers should always strive to create the best possible experience for their users.

If it were up to me, I would choose Adaptive Images. It is the cleanest and easiest solution I have found. But that choice is based solely on opinion as I have not actually tried it or any of the aforementioned methods. However, I know how frustrating it can be to implement new technologies to stay ahead of the curve and then have them not work for some unforeseen reason.

Do Your Homework

Until these methods become standard, do your homework. Research a lot of different options to find out which one is best. Take time and really consider what works best for you and your clients—just because something is the next big thing, it does not, and should not mean you jump off that proverbial bridge. As always, you should never implement any new technology without careful evaluation and testing.

As developers we can never know what our users are expecting, or what shiny new device is going to change everything—again (I’m looking at you iPhone 5!). But, we can be proactive and ready for what’s next. We must welcome change and embrace the possibility of the unknown. I know I would not have gone into this field if I wasn’t excited about new technologies and learning to be the best at what I do.

So, don’t be afraid what’s coming down the pike. Instead, take pride in knowing that by using a responsive image solution, you will be taking your site to a new level and providing the best possible experience for all your users.


Choosing A Responsive Image Solution – Smashing Magazine

Responsible Considerations For Responsive Web Design – Smashing Magazine

Clown Car Technique: Solving Adaptive Images In Responsive Web Design – Smashing Magazine

Adaptive images: solving the responsive image problem – Web Designer Depot

Picturefill Needs to Die – Oscar Godson

On Responsive Images – CSS Tricks

Which responsive images solution should you use? – CSS Tricks

Client Spotlight

Check out some of the work we've done to help these clients succeed: