Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

Choosing A Responsive Image Solution

If you code websites, it’s a good bet that at least one of your clients has asked about or requested a mobile-friendly website. If you go the responsive design route (whereby your website is flexible enough to adjust visually from mobile to desktop widths), then you’ll need a strategy to make images flexible, too — a responsive image solution.

The basics are fairly simple to learn, but once you’ve mastered them, you’ll find that scaling images is only the beginning — you might also have performance and art direction conundrums to solve. You’ll be faced with a wide field of responsive image solutions to choose from, each with its own strengths and weaknesses — and none of them is perfect! This article leads you through the basics, and then arms you with the information you’ll need to pick the best responsive image solution for your situation.

Further Reading on SmashingMag: Link

The Basics Link

Styling foreground images to adjust to the width of their container is very easy. In your style sheet, perhaps in your normalize or reset style sheet, you’d add the following code:

img {
    max-width: 100%;

In most cases, that tiny style rule will do the trick! Once it’s in place, if the container around the image becomes narrower than the width of the image, then the image will scale down to match the width of its container. Setting the max-width to 100% also ensures that the image does not scale larger than its actual size, which would significantly reduce the image’s quality. If you’re still stuck providing support for IE 6 or 7, you’ll want to add a width: 100% style rule targeted only to those browsers, because they don’t understand max-width.

High-resolution “Retina” images can make this basic implementation a bit tricky. Let’s say you want your 150 × 150-pixel logo to display at double the usual pixel density, and the image is small enough that having two separate versions wouldn’t be a problem. So, you create a 300 × 300-pixel version of the logo and plug it in — and now it’s huge! Your first inclination is probably to try something like this in CSS:

img.sitelogo {
    max-width: 150px;

Unfortunately, this doesn’t work as expected — the logo image will now refuse to scale nicely with the other images on the page.

To limit the maximum width of an adaptive image, you’d have to limit the maximum width of the image’s container, rather than of the image itself! Let’s say you’ve wrapped your logo image in a module with a class of branding. Here is the style that will do the trick:

.branding {
    max-width: 150px;

So, now we have scalable responsive images in our website’s fluid layout. Mission accomplished. Time to go find out what this strange “outdoors” place has to offer to a sun-starved developer, right?

Not so fast! We still have two main challenges to overcome.

The Performance Problem Link

With the responsive image solution outlined above, all devices are fed the same images. Small icons and logos might not be too bad, but the problem compounds quickly as the images get larger and heftier. Retina images exacerbate the problem — you don’t want to send a big Retina image to a device that isn’t capable of displaying its full detail!

Think about it. Should we really be sending a 990 × 300-pixel 100 KB image meant for desktop viewers to a mobile phone? Sure, the mobile visitor might be on their local coffee shop’s Wi-Fi connection — however, they might be on the road trying to get crucial information from your website, with one shaky bar of wireless service. Every mobile user who gives up when your page takes too long to load is a potential customer lost!

Many mobile websites that are just as big or bigger than their desktop counterparts can be found in the wild today. Guy Podjarny5 ran some tests a year apart, and there hasn’t been much improvement: in 2011, 86% of websites were the same size or larger, and in 2012 that number went down to 72%, but the overall sizes of websites increased. Dave Rupert also captured the problem beautifully in his article “Mo’ Pixels Mo’ Problems6.”

Complicating It Further: Browser Preloading Link

When I first began wrestling with performance issues on responsive websites, my initial thought was to put all of the image variations on the page, and set up some CSS classes with media queries that would hide big images and show small images at small widths, and vice versa at desktop widths. It seemed logical: shouldn’t the browser only download the visible images?

The problem is that browsers are too quick for us! In order to provide the fastest loading time possible, browsers preload all of the images that they can identify in the source code before any CSS or JavaScript is processed. So, this approach would actually penalize mobile visitors more, by forcing them to download all of an image’s variants!

Because of this preloading, most solutions require either a back-end solution (to preempt the preloading) or special markup and JavaScript.

Bandwidth Detection Link

The last piece of the performance puzzle is network speed. We know that we want to feed only the large images to devices that are on a speedy network, but how do we determine that? A few techniques are out there to estimate network speed, but they aren’t foolproof yet.

The W3C has been working on a Network Information API7, which could be very helpful in future, but currently it’s supported by only a handful of devices (and not the big ones, unfortunately). It is currently implemented in a few responsive image solutions, but I don’t expect it to be widely adopted until it’s more widely supported. Network measurements are difficult8 and as Yoav Weiss states in his Smashing Magazine’s article, reliable “bandwidth media queries” don’t seem to be something that can be accurately implemented in the near future.

Foresight.js9 by Adam Bradley10 uses JavaScript to test how long the browser takes to download a 50K image, then stores that information and uses it to make bandwidth decisions. It does have a few small drawbacks: it does add a 50K image download to your page, and it can block download of other images on your page until the test image download is complete. Many of the responsive image solutions that currently implement bandwidth detection use a variation or adaptation of Foresight.js.

The “Art Direction” Problem Link

Let’s say you’ve got a beautiful wide image on your home page. It shows a wide bucolic expanse of fields and forest, blue sky and fluffy clouds above, and a happy family having a picnic on the grass.

Now scale it down to 300 pixels wide, mobile-style. At this scale, our vacationing family looks more like the ants at the picnic!

Detail is lost when this large image is scaled down. (Image: Mark McQuitty12)

Herein lies what we call the “art direction” problem. Some images just don’t scale well; fine detail is lost, and dramatic impact is reduced. In the case of our hero image, it would be much nicer visually if the mobile version of the photo was zoomed in, cropped and focused on our happy family. To solve this problem, we need a responsive image solution that enables you either to specify different versions of the image for different situations or to adjust the image on the fly.

Sometimes a different crop or zoom of the image is desirable for narrow widths. (Images: Mark McQuitty14)

Choosing Your Solution Link

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?

Choosing between them can be an extremely complicated matter, because so many factors come into play. No current solution is perfect for every situation; each was designed to solve a particular set of problems. To decide, you’ll need to weigh each solution against your project’s particular needs. Chris Coyier has done a great job of summarizing the deciding factors15 (including a spreadsheet to track them all, although some newer solutions aren’t mentioned).

Here are some factors to consider:

  • Do you need to solve the art direction problem (i.e. different image ratios, crops and sizes for different widths)?
  • Do you have a huge website or a CMS on which going back to add special markup to every image is not feasible?
  • Are all images present upon the page loading, or are some images loaded dynamically via JavaScript?
  • Do you want to test for the user’s bandwidth to determine whether their connection is fast enough to handle high-resolution images?
  • Does the solution require a platform that is unavailable to you (such as jQuery or PHP)?
  • Is a third-party solution acceptable, or do you need to keep the solution hosted in-house?

With this in mind, let’s look at some responsive image solutions that have been out there for a while and that are widely used within the developer community.

Please note: The list of solutions below is by no means comprehensive. They are the ones either that I’ve found most useful personally or that have proven track records for reliability. Have a favorite solution of your own that’s not here? Let us know in the comments!

Tried And True Responsive Image Solutions Link

Picturefill Link

The Web is truly worldwide, and we have to confront the fact that not everyone has access to fiberoptic connections and 4G networks. Scott Jehl16 encountered this digital divide first-hand while travelling and working his way through Southeast Asia, and he is a strong advocate of mobile-first and responsive websites that don’t put an undue burden on mobile users. His Picturefill17 script is a polyfill for the proposed <picture> element — JavaScript code that mimics the picture API, enabling us to use it on our websites today. The future is now, baby!

Picturefill does not require jQuery, but obviously it does require the picturefill.js script to be included somewhere in the page. Picturefill also requires some special markup, with divs to represent the image variations, differentiated by data-media attributes that act just like media queries in CSS. You may also optionally put an image in conditional comments for browsers that don’t support media queries (I’m looking at you, IE 8), and a fallback in a <noscript> tag for browsers that don’t have JavaScript enabled (I’m looking at you, BlackBerry).

Here’s an example of a typical Picturefill setup:

<span data-picture data-alt="Descriptive alt tag">
    <span data-src="images/myimage_sm.jpg"></span>
    <span data-src="images/myimage_lg.jpg" data-media="(min-width: 600px)"></span>

    <!--[if (lt IE 10) & (!IEMobile)]>
    <span data-src="images/myimage_sm.jpg"></span>

    <!-- Fallback content for non-JS browsers. -->
        <img src="images/myimage_sm.jpg" alt="Descriptive alt tag" />

That’s all you need to display adaptive images at page-loading time using Picturefill. Drop in the script, configure the markup, and everything just works. You can also call Picturefill programmatically if you need to add images to the page on the fly.

Picturefill requires a lot of custom markup, so it might not be the best choice for those who cannot alter their website’s source code for any reason. It also doesn’t do any bandwidth detection. If bandwidth detection is important to your project, then have a look at this next solution.

HiSRC Link

HiSRC18, by Marc Grabanski19 and Christopher Schmitt20, is a jQuery plugin that enables you to create low-, medium- and high-resolution versions of an image, and the script will show the appropriate one based on Retina-readiness and network speed.


To set it up, first make sure that jQuery and the HiSRC script is included somewhere on the page.

In your HTML code, first add a regular image tag to the page, and set the source to be the low-resolution (or smallest) version of the image. Add a class to the image or its wrapper (like .hisrc) to specify which images HiSRC should process. Then, add some special markup to your image tag: data-1x and data-2x attributes, pointing to the medium- and high-resolution versions, respectively. For example:

<img src="" data-1x="" data-2x="" class="hisrc" />

Then, after the DOM has loaded, just call the function on the image class that you’re using, like so:


In practice, the browser will first load the image source — i.e. the mobile version of the image. Then, the script checks to see whether the visitor is using mobile bandwidth (such as 3G). If so, it leaves the mobile-first image in place. If the connection is speedy and the browser supports a Retina image, then the @2x version is delivered. If the connection is speedy but Retina is not supported, then the @1x version is delivered.

You might have noticed that the low-resolution image always loads, even if the script later decides that the user’s device is a good candidate for high resolution. Even though this is technically a double-download, it only penalizes those on speedy connections. I’m willing to accept that compromise!

HiSRC can handle images that are added to the page dynamically. It also allows for multiple images, so you can specify different crops and sizes to beat the art-direction problem.

As for weaknesses, HiSRC does require jQuery, so it won’t be useful unless you’re using that library. It also requires custom markup in the HTML, so it might not be the best choice if you have a huge website with a lot of legacy images or a CMS in which the output of the image tag can’t be altered. If that’s your situation, read on!

Adaptive Images Link

Unlike the previous two scripts, Adaptive Images22, by Matt Wilcox23, is mostly a server-side solution. It requires a tiny bit of JavaScript, but the real work is done via the Apache 2 Web server, PHP 5.x and the GD library.

To install it on your Web server, you’ll need to alter or add an .htaccess file, upload some PHP files to your website’s root directory, add some JavaScript to your pages (which will add a cookie to record the user’s screen resolution), and configure some breakpoint variables in the PHP files to match your website’s media queries.


The installation instructions are quite verbose — a bit too lengthy for the scope of this article. For more information, visit the official website and click the “Details” link at the top.

The best feature of Adaptive Images is that it requires no custom markup on any of your images. Once you’ve installed and configured it correctly, you’re all set! The PHP script will intercept any request for an image and will resize it on the fly as needed to your specified breakpoint sizes and serve it on your pages automatically.

The PHP has a lot of configurable options, such as image quality, breakpoints, caching, and even a sharpening filter to apply to the generated scaled images.

It has a few limitations:

  • Because it requires the combination of Apache and PHP, Adaptive Images might not match up with your website’s platform or be available on your Web host’s server.
  • It relies on the Web server’s ability to intercept any requests for images (via the .htaccess file). So, if your images are hosted elsewhere, such as on a content delivery network, then it won’t work.
  • It doesn’t detect bandwidth.
  • It’s not meant to solve the art direction problem, because it only rescales the original images. It can’t crop or create different aspect ratios from the original image.

You may have noticed that all of the solutions thus far require JavaScript, and often some detailed configuration. If you’re looking for one that doesn’t require JavaScript and that is fairly simple to implement, then have a look at this next one. Src Link

Previously known as TinySrc, Src25 is a third-party solution that acts as a proxy for images, so you don’t need to configure anything on your server. Just point your image at Sencha’s servers (with or without some options specified), and Sencha will process it and send back a resized version as needed.


Let’s say you have a big image:

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

At its simplest, you’d just prefix the src attribute with, like so:

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

By default, will resize your image to fit the width of the device’s screen, using the user-agent string for detection. Phones might be sent a 320-pixel-wide image, tablets a 768-pixel-wide image, etc.

You can also configure the prefix string to return particular measurements, orientations, percentage sizes or any number of complex calculations. is a free service for individual users and can be a very convenient adaptive image solution. However, you’re adding a third-party dependency, with the possibility of downtime and problems beyond your control. Weigh these risks carefully.

Responsive Image Solutions To Watch Link

The solutions outlined till now are usable today, but they’re not the only fish in the sea. Some newer solutions show a lot of promise, and I’m keeping a sharp eye on them to see how they evolve with current Web technology. Below are two in particular that you might want to watch.

Capturing/Mobify.js 2.0 Link

Capturing27 is a new feature of the in-development Mobify.js 2.0, which proposes to give you access to (or to “capture”) the HTML source markup before it is parsed or rendered by the browser. Accessing the source code at this stage enables you to swap an image’s src attribute before the browser downloads it. You can even craft a fallback to one of the other solutions, such as Picturefill, in case something fails.


Since this technique directly circumvents native browser preloading, it is a bit controversial in web performance circles. If misused, it could actually create performance problems on a site instead of alleviating them!

The other thing holding me back from running to this solution with open arms is its cross-browser support. Capturing won’t work in any version of IE lower than 10, so IE 8 and 9 users will be left out in the cold. I’ll keep watching, though — down the road a ways, when IE 8 and 9 finally fade into the sunset, this solution might be more viable!

If you’re interested in finding out more about Capturing, the Mozilla team goes into more detail in its blog post, “Capturing: Improving Performance of the Adaptive Web29.” Link

ReSRC.it30 is another third-party solution (recently out of beta) that delivers responsive images from the cloud. It seems to be very similar in implementation to Src, but adds image filters and bandwidth detection and doesn’t rely on user-agent detection or cookies.


To get started, you first need to sign up for a trial account at

Second, you’ll need to insert their Javascript file on your page (this is the simple JS code; they offer an asynchronous embed method as well to improve performance):

<script src="//"></script>

Then, suppose you have an image like this:

<img src="http://path/to/image.jpg" alt="My large image" />

You would prefix the image source’s URL with a path to’s servers, and add a CSS class of “resrc” to the image. They currently have two servers, one for paid accounts and one for trial accounts — we’ll use the trial one for our example:

<img src="" alt="My large image" class="resrc" /> allows you to add parameters to the requested URL to perform operations on the image, such as rotating, cropping and flipping. This allows for quite a bit of flexibility and potentially addresses the art-direction problem. The parameters are processed in order from left to right and can be strung together.

Here’s an example of an image that’s being flipped horizontally, resized to 300-pixels wide, with the resulting image optimized to an 80%-quality JPEG:

<img src="" alt="My large image" class="resrc" /> is recently out of beta, so if anyone using the service has tips or advice (pro or con), we’d love to hear more about it in the comments.

Test, Test, Test! Link

After you’ve chosen and implemented a responsive image solution, testing the performance of your website is absolutely necessary to making sure that the solution is working well. Below are a few useful online testing tools to help you.

YSlow Link

Created by Yahoo, YSlow32 is a client-side tool that analyzes your website against 23 testable rules that Yahoo has determined can adversely affect Web page performance. YSlow awards your website a grade for each rule, explaining each one and suggesting how to improve your website’s performance. YSlow is available for Firefox, Chrome, Safari and Opera (as well as by a few other means, such as the command line).

WebPageTest Link

The online tool WebPageTest33 is an open-source project maintained by Google. You enter your website’s URL, perform a speed test from a chosen location, and specify which browser to use. Advanced settings allow you to perform multi-step transactions, pick a network speed (cable, DSL, FiOS, etc.), disable JavaScript, block ads and make other requests, and more. The results come in the form of tables, charts, screenshots, a performance review and a lot of great data to dig into!

The Yottaa blog has an article detailing how they used WebPageTest to test out their website both with and without responsive image loading34 — check it out!

Conclusion Link

If you read Smashing Magazine, you’re probably already on board with creating the best possible website experience for your audience. So, the next time you craft a beautiful, usable experience for mobile visitors, try out one of these responsive image solutions and take your website the extra mile. Your mobile visitors will thank you!

Delve Deeper Link


Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 35
  36. 36
  37. 37
  38. 38
  39. 39

↑ Back to top Tweet itShare on Facebook

Sherri Alexander is a front-end developer in the Boston area who delights in bringing web designs to life. She's been making browsers dance to her tune since the olden days of the web, when background images were a neat new idea. When she's not coding, Sherri indulges her inner geek by watching Mythbusters, playing video games, and hosting tabletop gaming nights.

  1. 1

    Jamie Mason

    July 8, 2013 2:04 am

    Hey guys, one thing to mention is came out of beta recently.

  2. 7

    Nice to hear that there are other alternative solutions to Sencha. It would be amazing if Amazon could add something similar on S3.
    Anyway, I always find really helpful Slowy app to test pages and images performance, basically it allows you to SEE the page loading.

    • 8

      Sherri Alexander

      July 8, 2013 10:05 am

      Hi Geppo,

      Oh excellent, I’m always happy to add a new tool to my performance-testing toolbox. Slowy looks like an interesting Mac app — thank you for bringing it to my attention!

      • 9

        Apple’s Xcode has some extra tools available for download, one of which is a preference pane called Network Link Conditioner that looks like it does the same thing as Slowy with a list of defaults and the ability to add your own.

        If you have Xcode installed, go to the Xcode menu, and from the Open Developer Tools submenu, choose More Developer Tools…

        On the webpage that comes up, the prefpane is part of the Hardware IO Tools for Xcode disk image.

  3. 10

    Another one >

  4. 11

    Hjörtur Hilmarsson

    July 8, 2013 2:08 am

    Thanks for the article!

    It’s a really good list of options as it’s can be a complicated problem to solve.

    There is also another service for images called, might be worth the look.

    • 12

      Sherri Alexander

      July 8, 2013 5:08 pm

      Hi Hjörtur,

      There certainly are a lot of responsive image solutions out there right now — more than any one person could possibly collect ! Thank you for bringing this one to my attention, I will definitely be checking them out (looks like they’re in beta at the moment, but might still be fun to sign up and play with).

  5. 13

    Kenneth Jensen

    July 8, 2013 2:19 am

    Just what I was looking for. Thanx Smashing

  6. 14

    Andy Davies

    July 8, 2013 2:40 am

    The browser pre-loader is a bit more subtle than outlined above…

    When the browser is blocked e.g. the CSS needed to render the page hasn’t finished downloading, or there’s a script that needs to be downloaded an executed, the pre-loader/fetcher will do a lightweight scan of the page looking for other resources it can schedule for downloading.

    Some browsers then prioritise the order resources discovered are downloaded in e.g. Chrome prioritises blocking resources such as CSS, JS, fonts over images, Firefox does something similar.

    So it’s more of a case that browsers will have scheduled the download of images found rather than the images actually having been downloaded before CSS or JSS is processed.

    Some people find the preloader behaviour frustrating but it’s important to making the most of the network connection and overcoming latency as Ilya illustrates, the preloader in Chrome delivers at 20% speed improvement in page download times –

    • 15

      Sherri Alexander

      July 8, 2013 5:16 pm

      Hi Andy,

      There’s definitely a lot more complexity going on under the hood of the browsers than I’ve described — you’ve summed it up perfectly in your comment. The article is more of a “10,000 foot view” of the problem and solutions, so I didn’t go into much detail about what’s actually occurring when browsers query servers. It’s pretty interesting stuff though, and I know that the browser makers are struggling with these issues of performance, latency and bandwidth as much as we developers are. Thanks for commenting and shedding more light on that piece of the puzzle!

  7. 16

    Douglas Bonneville

    July 8, 2013 11:58 am

    I remember not too long ago when web design was fun.

    None of this is fun anymore. It takes half-a-dozen js libraries on top of some flavor of HTML5 boilerplate – all before you even look at a CMS – to get going with responsive design. It’s more like we are crossing the threshold into a new paradigm were fully-baked software platforms will have to create and manage website development.

    It’s getting to the point where making a website is like coding an illustration by hand in SVG, or coding a PDF in PostScript by hand. Sure you can do it, but those technologies, especially PostScript, made fully-baked IDEs for creating documents based on it a sure necessity. Where is the Quark, PageMaker, InDesign, Illustrator for websites going to come from? Does Adobe have anything up their sleeves?

    And if you flip over to app development – man that sure looks a lot more fun by comparison!

    I think my philosophical waxing about responsive web design was finally terminated by the all-of-them-are-too-complicated solutions around images. Or rather, they are too-complicated to be *fun*…

    • 17

      Yeah, I agree wholeheartedly. And I know it makes me sound like an old man, but all of it – the responsive, cross-browser, cross-platform, backwards-compatibility, etc. etc… It’s just garbage.

      Too many isolated interests operating outside of any common standards, leading to infinite fragmentation. I feel like we’re auto mechanics who’re expected to be able to work on steam-powered cars, horse-carriages and electric vehicles. There’s all these ways to cobble sites together, but it all hinges on stop-gap solutions that will be invalidated as soon as one of the many players decides to do stop something that the rest of the community accepts. With the hyper-pace of rollouts, who has time to relearn everything? Why stay current with Flash when it’s done a lousy job of staying relevant to platforms?

      It’s not just that it’s not “fun” anymore, it’s just an insane waste of time and resources to devote to skinning the same cat 15 different ways.

  8. 18

    What would be nice is to have an OpenSource script equivalent to the Src or that we could install on our server. Anyone knows about an existing one?

    By the way, thanks for the article.

    • 19

      Yes, I’m sure someone will put together an open source offering at some point.
      But the problem really is that it take a pretty hefty web server to be able to resize images on-demand effectively. Cloud services benefit from the economies of scale and optimisations associated with just doing one thing – delivering images.

    • 20

      Check out this one:

      A friend is recently working on it.

  9. 21

    Michael Lasell

    July 8, 2013 5:15 am

    Can this problem be solved by using jquery .load() or other ajax to load different page content dependent on browser width (or whatever else needs to be detected)? The parent page would have no image content, a script would choose the correct child page with varied image content. Pretty straight-forward – no extra libraries outside of jquery or zepto.

  10. 22 can also serve files over https to avoid the IE mixed content message warnings – Sencha can’t unfortunately.

    • 23

      Sherri Alexander

      July 8, 2013 5:24 pm

      Hi Tim,

      Excellent point — I wasn’t aware of that particular limitation of Thank you for mentioning it!

  11. 24

    Thank you for this excellent overview! (Standing, applauding, throwing roses:)

  12. 25

    Stephane Bourbeau

    July 8, 2013 6:04 am

    One important drawback of PictureFill solutions is that Search Engine Bot do not index images (even those included in the noscript tag).
    Otherwise, great summary on available solutions, thanks

  13. 26

    L. Mitchell

    July 8, 2013 6:11 am

    Thanks for the article!

    The point about horizontal “homepage hero” photos losing their visual impact when scaled down for mobile is especially important.

    The hero homepage photo image strategy isn’t going away anytime soon, at least from what I’ve seen from my clients. This is both because brand people and clients love them for messaging, as well as because many analytics reports that I’ve seen show that homepage heroes do generate a lot of clicks.

    I’ll be sure to mention the use of alternate vertical hero shots for mobile to my clients from now on.

  14. 27

    I think it would be worth noting a solution that requires no plugin. It may not be perfectly semantic, but using background images instead of img tags gives you more control over loading the image at different screen widths. You lose being able to scale these nicely in ie 8 and below though, so you’ll need to come up with a nice fallback for those browsers. See

    • 28

      Sherri Alexander

      July 8, 2013 10:37 am

      Hi TJ,

      That’s very true — if you don’t have to support IE8 (and how I’m waiting for that day to come with my own projects!), this method could work well.

      One possible problem I could foresee would be how to integrate that technique nicely with a CMS system, though. So many sites I’ve worked on have some sort of back-end system calling the shots, and the end clients want to be able to click a button and insert an image without having to mess about with stylesheets. I suppose inline styles might be an option if the CMS allows that sort of customization though. Printing could also be a bit tricky, since many browsers *still* default to background images turned off, so you might not want to do this with your site’s logo.

      Has anyone else experimented with this technique? Chime on in!

      • 29

        We support ie in that its functional. We don’t support it to be responsive though. We’re more of the philosophy that if the browser doesn’t natively support something, we shouldn’t jump through hoops to force it. I think Kyle Simpson nailed it in this presentation

        Good call on the CMS though. I suppose it would have to be done with inline styles, and the server making new images for different widths.If I had to choose from above, I like hisrc the best. The part where it downloads a 50k image to test the connection is the only thing I don’t like. Too bad there isn’t a better way to do it yet.

      • 30

        Parker Bennett

        July 10, 2013 8:11 am

        For what it’s worth, I outlined a tweaky way to use multiple-backgrounds for a more refined experience when using media queries to serve different background images. With a polyfill or two it works in IE8 and solves the art direction problem to a degree:

      • 31

        Best solution to this problem is use a better CMS. Restrictive blogging platforms (ala WordPress) are great for theme-driven blogs – but they’re not real CMS’s that should be used for bespoke work – it’s a hamfisted and heavy-weight solution for 99% of websites.

        If you’re using a good platform then the fact it’s a background image shouldn’t make any difference.

  15. 32

    Anthony Hortin

    July 8, 2013 6:39 am

    Great post. Lots of great resources there. Thanks!

    Another interesting solution that I just found out about tonight, is Metaquery, by Ben Schwarz. It allows you to define your breakpoints using meta data. –

  16. 33

    I prefer server-side solutions that just dynamically work their mojo on all images. You can just upload the big ones and it’s all taken care of; I can hassle with installing once, and then only occasionally mess with to tweak settings as standards [constantly/nauseatingly] change. Here’s hoping that future versions of things like Worpdress and Drupal have baked-in solutions.

    • 34

      Actually, Drupal 8 (currently in beta) has a nice solution already in core, by using the original recomendation, called the Picture module.

      They’ve also made a backport to Drupal 7 (including a alternative weblinc pollyfill for older browsers) that works in conjunction with a Breakpoints module.

      Pictures Module:
      Breakpoints Module:

      Dev versions are also juggling with inline-images and colorbox support.

      Simply put, it detects the viewport size, which then triggers the images to be displayed with a different media style (in Drupal this basically means different sizes – real file resizes done in the server, not just browser zooming).

      I’ve made a small video tutorial regarding this specific issue in Drupal (not too fancy, but ok I guess). You can find it here:

      Hope it helps.

  17. 35

    Squeeze Digital

    July 8, 2013 7:55 am

    + 1 here for

    We’ve been working with the guys there during their beta period and have our first commercial site going live with them in the next three weeks.

    The support we’ve had so far is great and the product is second to none. We now develop responsive exclusively and plan to use on all our projects.

  18. 36

    You have a false statement right off the bat in the article. max-width: 100% on an image tells it to have a max-width of 100% of its parent.

    If the image is 100px wide and its parent is 500px wide, the image’s max-width is 500px.

    • 37

      Sherri Alexander

      July 8, 2013 10:02 am

      Hi Julian,

      I know, it sounds like that would be the case, but it actually works! Browsers seem to interpret this CSS rule as “don’t go wider than your native width” when it’s applied to images. I’ve created a very quick example on CodePen to demonstrate, with a 100px kitten image inside a 500px wide container: (you may need to click on “Edit Pen” at the very bottom, to see the full HTML/CSS code that’s being used).

      Thanks for commenting!

      • 38

        In your code pen add: width:800px to your img style. The image now appears at 500px wide because max-width:100% means “this element will be no larger than 100% of its parent”

        It does not mean it will be rendered no larger than 100% of its own size.

    • 39

      Not true. If have max-width:100% set the image will only go as wide as its native resolution.


      • 40

        No. i tried this and is working as Sherri has said. by the way Andrew even your example shows 200px img and container with 400px as it should be.

        • 41

          I think you may be confused. I actually agree with Sherri, we both replied to Julian with the same point, just at different times.

  19. 42

    Danny Lewandowski

    July 8, 2013 8:11 am

    Zurb has released their “Interchange” plug in for responsive images as well. It integrates in their Foundation framework seamlessly and is very easy to implement.

  20. 44

    I’ve found a way to solve the “Art Direction” problem with responsive images here:

    It involves a little known variant of background-position

  21. 45

    Joschi Kuphal

    July 8, 2013 10:20 am

    Thanks for this great article and the pretty comprehensive overview! Please allow me to add my recently beta-released “squeezr” ( to the list of server-side solutions. Basically, it does pretty much the same as Matt Wilcox’ Adaptive Images, but it deals with some of the problems I experienced with AI. Most notably squeezr

    – doesn’t employ PHP for each and every image request, but leverages Apache’s mod_rewrite to deliver already cached image variants,
    – supports 8-bit PNG images,
    – uses symlinks and optimized cache HTTP headers so that even unmodified images get properly cached by the client browser,
    – and some more …

    For the future im planning to add support for server-side device detection (e.g. WURFL), so that even clients without JavaScript support can be served as well.

    Besides the responsive image problem, squeezr also implements some sort of server side CSS3 media queries. Analogous to the image re-scaling, it uses the client’s screen dimensions for analysing CSS files and stripping out irrelevant media query sections, optionally applying CSS minification as well. Along with the image re-scaling this might further improve the bandwidth saving dramatically (especially for devices with small screens).

    The squeezr website has a test drive feature, so you can easily figure out the bandwidth reduction squeezr could achieve for your website (there are some limitations for these tests though):

    Please check out squeezr and download it from the website or from GitHub. I’d love to get your feedback!

  22. 46

    Another solution that was not yet mentioned is squeezr ( Besides doing pretty much the same as Matt Wilcox’ Adaptive Images, it also analyses the CSS and strips out irrelevant mediaqueries.

  23. 47

    Does anyone have a suggestion if using external tools are prohibited and a CDN should be used?

    Which solution is also best for SEO under this circumstances?

  24. 48

    Shawn Jansepar

    July 8, 2013 2:58 pm

    Thanks for including Mobify.js in this list! We are really looking forward to feedback from the community :) Here are a couple of additional pieces of information about it that I think readers might be interested in:

    – While Mobify.js doesn’t resize images for IE8/9, since it doesn’t require you to change `src` attributes into `data-src`, the original images will still load on those browsers.

    – You can also use the Image API in Mobify.js without turning off the pre-parser (aka Capturing) if you are willing to change `src` to `data-src`.

    – Another interesting part of Mobify.js is that it also resizes elements automatically, which is useful because you can continue using the element to solve the art direction problem, but you don’t need to create six different assets for the same image to solve the performance problem. (

  25. 49

    Great article, thanks for laying everything out so clearly. I’m bookmarking it so I can refer back right before I start coding my next project. Just one thing though:

    “…however, they might be on the road trying to get crucial information from your website, with one shaky bar of wireless service.”

    Could it possibly say “on the go” instead of “on the road”? Every time I think about it I just see someone swerving across four lanes of traffic trying to scroll past a huge, yet-to-load image to get to a company’s address… oy…!

  26. 50

    Lovely article, Sherri. Great to see everything consolidated into one place and explained so succinctly.

    I’ve tweeted about this pet peeve in the past, but definitely worth mentioning here: I’d really like to see the industry move away from using the term “art direction” for just issues with images in responsive web design. Professional art direction entails a lot more than just cropping pictures to fit, and I’ve always felt the term is both not descriptive enough, and also a disservice to legit Art/Creative Directors (as an aside: I’m not one, but I have a healthy respect for the job).

    So, as to not make this post just useless complaining, I’m proposing the term “contextual cropping” in its place. That’s just what I came up with on the fly, definitely open to a dialogue/other suggestions!

  27. 51

    Andrew Hallock

    July 9, 2013 1:09 pm

    In the “img.sitelogo” example you said that setting the max-width on the double-pixel image would not work and that you have to set max-width on the container, instead. I’m not to clear is to why setting it on the image would not allow it to scale correctly.

    • 52

      Andrew Hallock

      July 9, 2013 1:33 pm

      Never mind, I see now. I was dreaming up magical abilities CSS doesn’t have, like applying the original max-width: 100% once the container was less than 150px wide.

  28. 53

    I’ve been using a CSS solution for responsive images. Small images are used in the markup — then with media queries for larger screens I call the small images to be invisible and use CSS background images for the larger sizes. Solves the art direction problem because the small images can be cropped, while the large images remain big and beautiful. No javascript to contend with. No need for fall-back. No extra mark-up. Of course, it requires more CSS (not to mention managing image code in two places). But for smaller sites it’s manageable.

  29. 54

    Benjamin L.

    July 9, 2013 10:56 pm

    Hi, very nice article. Thank you. Juste a question : in this article, you talk about retina (ie.iOS). We all know that’s pretty *simple* to support (basically x2). But what about Android devices support ? Is this the same ? I am not sure of that as we work on ldpi, mdpi, hdpi, xhdpi things. What do you think ?

  30. 55

    John Rygielski

    July 10, 2013 9:01 am

    I keep reading articles on responsive images that assume Retina resolution images are always too heavy for mobile downloads, ignoring compression abilities. Double-resolution images can be much more compressed, even to the point where they are smaller in file size than their standard-resolution counterparts, while maintaining their detail. Whereas a typical JPEG maybe be saved at 80% quality, an @2X version can be saved at 30% quality, be a smaller download, and still look great on a high-dpi or standard screen alike.

    It does offload resizing to the browser but, that can be less expensive performance-wise than the extra requests and JS used in other methods. It’s not the solution for everything, but it should at least be part of the conversation, and it’s missing here.

    • 56

      This is the method I prefer also. No dealing with multiple images or extra coding or js bloat. I was also surprised it wasn’t mentioned. Good call John :)

    • 57

      I am moving towards this now. Sadly, the CMS we use has a cropping feature that doesn’t allow for this. Anything I put in manually, I can do it with, but anything any of our content contributors add, it won’t happen.

      But, in my tests, depending on how much extra resolution, you can go to 15% or 20% on a jpg and have a very viewable image that looks sharper on Retina and normal displays.

  31. 58

    Patrick Samphire

    July 11, 2013 8:13 am

    One of the big problems I’ve come across with the more automated solutions is that they aren’t context-dependent. By this I mean that they look at the size of the browser window rather than the size of the whatever section of the screen the image happens to be in.

    For example, a full-width image on a, say, 1000px-wide browser window should be 1000px wide. But what if the browser window is 1000px wide, but the image is actually going into a 200px-wide sidebar. Delivering a 1000px image in that context would be crazy.

    Has anyone come across a solution that actually looks at the size of the container the image is within?

    • 59

      Shawn Jansepar

      July 12, 2013 2:20 pm

      Hey Patrick,

      One of the issues with attempting to create an automated solution that only downloads as much as needed based on the container/layout is that it takes a while for the CSS Object Model to generate before being able to figure out how big the image will need to be. That means that you would have to wait for all of that processing to happen before starting the download of that image, and rendering takes quite a bit of time. The goal should be to start the download of images as fast as possible!

      With Mobify.js, we came up with a compromise to this problem – use the element to be able to override the widths at different breakpoints, and let the Image API take care of that resizing automatically (so you don’t need to create each image asset yourself)! Check it out:

  32. 60

    Another service that solves these problems is
    With its api you can resize, add filters and alter in several ways your original images on the fly.
    There are some interesting extra features too, like smart-cropping and retina ready image serving. Worth giving it a try:

    A quick off topic comment: The guy behind is one of the founders of Panoramio :)

    • 61

      I’ve tested and it’s SO SO SO SO good :D it improves your website performance!
      Thanks for the tip!

  33. 62

    I like the idea of solving the art direction problem with selected images that are suitable for specific widths, but I can’t see this as a viable option for large cms websites. It would also likely rely on fixed breakpoints which isn’t truly responsive web design. As stated though, we must do what is most suitable for the project in hand.

  34. 63

    I’ve been wrestling with high resolution screen dynamics lately. Here is a llnk where I outlined the technique I use.

  35. 64

    Nice article, yet I find it is key to at least mention this technique:

    Summary: double the dimensions of your image, then very heavily compress it, then show it at 50%. The results are phenomenal: excellent image quality at a moderate file size. In some/many cases, this could mean you can serve a single image for all/most resolutions. Limitations: only for JPEG, and does not include art directions.

  36. 65

    Could the desktop browser download one of the high res images due to having a faster connection speed and also due to an HD display? Or should it only download the original image within the “src” attribute?

  37. 66

    it is so imperative to have a website that can be accessed from any device, irrespective of screen size now a days ,we have been using jquery for our scrolling images,and they are coming out clear and seems to be working quite effectively.

  38. 67

    Elijah Dugan

    August 2, 2013 6:42 am

    Think about how many apps you use per day and how you have downloaded to your mobile device. It’s probably a lot, huh? This is reason enough for a business to invest in app development from a company like ConvoSpark can create an application that meets all of your company’s requirements and plays to your customers’ interests and needs.

  39. 68

    “In order to provide the fastest loading time possible, browsers preload all of the images that they can identify in the source code before any CSS or JavaScript is processed.”

    That sounds like something browser makers need to fix.

  40. 69

    Fernando seminario

    August 13, 2013 7:00 am

    Thanks for writing this up. I found it useful since I’ve been out of the responsive scene for a while.

    Another good testing tool is Loads in real-time.

  41. 70

    1) The information in chapter “The Basics” is wrong. it works as expected with the following css, look here:

    2) The information in chapter “Complicating It Further: Browser Preloading”” is wrong.
    Look at this article:

    I still haven’t read the rest of this article, maybe there are more wrong informations. please make better researches before writing such an article.

  42. 71

    What if I don’t want to load certain code or images if the user’s screen is a certain size? I know I can use CSS3 media queries for responsive design, but can I use them, or something similar, to not waste the mobile user’s bandwidth by downloading these huge images and other unused code, like javascript that I only want to run on the desktop? I understand that I could use CSS background images, but my current situation doesn’t lend itself to that (I’m using a WordPress full-screen background slideshow called WP Supersized, which outputs img tags). Basically, can I control HTML content responsively? Or tie it to JS to that code doesn’t run if the screen is less than 768px?

    • 72

      Figured out a solution: ‘window.innerWidth’ gives you the browser width in javascript

  43. 73

    Krzysztof Karski

    September 24, 2013 10:45 am


    Thank you so much for this excellent write up on various responsive image techniques. It’s nice to see the lineup of server-side solutions which so often are overlooked by other articles on the same topic. I believe a server-side solution liberates designers from so much manual overhead in HTML markup (a la the proposed srcset or element standards) or just simply cropping and formatting images.

    I’d like to mention Pixtulate ( which is a new service for scaling, cropping and serving responsive images in addition to your lineup. One advantage of Pixtulate is we are able to crop server-side with art direction in mind and designers are able to setup their image treatment rules server-side rather than cramming all instructions into the image URL.

  44. 74

    Colin S pittendrigh

    November 1, 2013 6:24 am

    RE> “But the problem really is that it take a pretty hefty web server to be able to resize images on-demand effectively. ”

    There are numerous (mostly PHP that I’ve seen) ways for the server to recognize the current device, usually involving a double GET for the first page request. At that point a cookie or a SESSION variable is set, which allows the server to send an appropriate image for each page request from that point on. Rescaling on the fly is expensive. But you only need three or at most four image sizes. So keep them all on your server. Disk space is cheap. Am I missing something?

  45. 75

    Great article, well explained! It gave me good input on how to deal with responsive images. Thank you

  46. 76

    hey, i want to find a wordpress plugin which do that (responsive imgages auto). pls tell me. thanks.

  47. 77

    Thank you so much!

    After like 3 hours of googling and trying different plug ins I think the basic code above did the trick.

  48. 78

    Good article now that Google insights is forcing everyone to go mobile friendly. I was hoping that I could get some recommendations from some professionals. I maintenance a website and my banners are very large. I just compressed and optimized all the images at compressjpeg, that tool works very good. Now I am looking to reduce the pixel sizes. I have full width banners on my website, 1,901px × 441px which when I scale smaller, a gap appears to the right and left of the banner. What are full width recommended banner sizes? Second question, I have 300px × 300px photos on my website. When viewing these images on a cellular smartphone, I receive a horizontal scroll bar. What size should I remake 300px × 300px so I don’t receive the horizontal scroll bar when viewing on smartphone. Any recommendations would greatly help!


↑ Back to top