Cloud Four Blog

Technical notes, War stories and anecdotes

How do you pick responsive images breakpoints?

For a few months now, I’ve been puzzling over the question of how to pick responsive images breakpoints. It has become a koan to me—no more answerable than the sound of one hand clapping. And as long as I’m haunted by the question, I thought I would share the joy.

What responsive images am I talking about

First, let’s make sure we’re talking about the same thing. In this case, when I refer to responsive images, I’m not talking about:

  • An image that is edited depending on the size of the screen. (what I previously called the art direction use case.1)
  • Different images for different display densities.

What I am talking about is:

  • Selecting different image files with different resolutions of the same image based on the screen size.
  • A desire to provide these different image files so that a browser doesn’t download an unnecessarily large file.

Basically, the classic use case that got us all looking at responsive images in the first place.

Defining image breakpoints

In responsive designs, we refer to breakpoints as the screen widths at which media queries are used to make changes to the layout. These breakpoints should be determined by the content, not by common device dimensions.

(For more on setting responsive design breakpoints, I highly recommend this excerpt from Tim Kadlec’s new book Implementing Responsive Design)

Image breakpoints are similar. What are the screen widths at which you switch from one image file to another?

Shouldn’t image and responsive design breakpoints be the same?



Scott Jehl recently made this point on the WhatWG list:

In the responsive layouts I’ve worked on, content image sizes and their breakpoints were chosen for completely different reasons than the design (CSS) breakpoints: the former for sensible jumps in file size to match screen dimension and/or density, and the latter for how content modules are visibly designed at given viewport dimensions.

Design breakpoints can be plentiful, especially when factoring in all the minor and major tweaks in multi-column responsive layout. Yet for content images, I’ve found the need for fewer breakpoints, or even entirely different breakpoints than the design. In a site like the for example, 2-3 image sizes provide sensible jumps in file size, and because the images live a fluid layout, they scale to fill the layout gaps as the CSS breakpoints shift much more frequently around them.

So unless the image is changing in coordination with layout changes, the breakpoints for images do not need to coincide with the breakpoints for layout. In fact, coordinating them may be less ideal.

So how do we pick “sensible jumps in file size”?

This is the question that has been troubling me. If we’re going to tell people creating responsive designs that they shouldn’t tie their image breakpoints to their designs, what guidance can we give them on how many file sizes make sense and when should they switch to a different file size?

To wit, how do you determine what is an unnecessarily large file? Is that 1 byte? 10k? 20k?


On a large site with a mixture of gif, png, and jpg images, can you pick common image breakpoints? If so, how?

As I wrote a few months ago:

The problem is there is nothing intrinsic to the image that would guide you in deciding where you should switch from one size of the image to another. Whatever we select will be entirely arbitrary unless we base it on our design breakpoints.

And basing our image breakpoints on our design breakpoints is not ideal.

The correctly sized image

The only thing we can absolutely say about what size image should be used for a given screen size is that the ideal solution is one where the resolution of the image matches precisely the size that the image is in the page.

Of course, this isn’t practical unless we have find the holy grail of responsive images—a magical new image format where a single file provides all resolutions and the browser only has to download what it needs to fill the space on the page. And even if we find the format, we’d have to hope it wasn’t legally encumbered and that all of the browser makers could agree on it.2

In the meantime, I’m stuck pondering the question of what to tell people when they ask how many image sizes and what breakpoints should they use in their responsive designs.

If you have ideas, I’m all ears. But please explain how you come to that conclusion and how you would advise another designer, on a different project, to figure out what image breakpoints would make sense for them.

  1. Stephen Hay and I have been discussing how art direction may be misused as a label for this use case. We’ve been discussing different names for it, but haven’t settled on anything yet.

  2. The easiest thing to do in discussions about issues like this is to insist that we need a new image format. I understand the sentiment and if I had a magic wand, I’d make it happen. But until someone—and by someone I mean a large company with intellectual property and lawyers to back it up—steps forward to volunteer a new image format for consideration, we’re stuck with the cards we’ve been dealt. That means that sooner or later, we’re all going to be trying to figure out how to decide where to set image breakpoints.

22 Comments on “How do you pick responsive images breakpoints?”

  1. Chad says:

    You could use JavaScript to insert each image instead of HTML. Simply put JS in place of the image with a variable for the image name an another, specified on load, for the resolution. Concatenate the two and you should have different images for different devices. Thoughts?

    • Jason Grigsby says:

      @Chad I considered mentioning that you could set up a server that would resize the image to any given size as specified in URL parameters, which is what I think you are describing with your JS solution.

      But the problem with that approach is that the viewport size is variable. Do you watch window resize and request a new image every few milliseconds as the person resizes the browser?

      It would be better to continue to use the already downloaded image until the new viewport size was sufficiently different to warrant downloading a new image. Of course, defining sufficiently different gets us back to defining image breakpoints or something similar.

      • Chad says:

        No, I think that when you describe responsive design, the viewport would already be small or large. What you’re saying is that a person can resize their viewport. The issue with that is that a phone can’t resize to be larger and if a browser already loaded the page large first and they resize their viewport to test the responsiveness, then just scale the images down to the new size. But most people don’t resize their browser just to see what it would do.

  2. Daniel Smith says:

    I completely agree, break points and image size although connected should still be treated on their own. At the moment i try to just cope with one image for mobile and one for desktop, however with the introduction of retina displays adds a whole other dimension, should you have a higher resolution for those devices?
    The only hope in the future I can see is the tag as being discussed today over the tag.
    I see the advantage of a JavaScript fallback but there is an issue for those users who turn off JavaScript.
    Let’s hope something kicks in soon as I love using images in my sites. :)

  3. Yoav Weiss says:

    Hi Jason,

    Regarding the “magical” progressive image format, I did some experimentation with progressive JPEG a while back:

    It’s not ideal (nor magical) & it can be further optimized, but progressive JPEG can be used as a responsive image format, with some adjustments to the browsers image fetching mechanisms.

    Regarding the breakpoints for the responsive images, IMO it depends on the images themselves.
    The best image breakpoint are a few “ideal” dimensions where a slightly wider/taller image will be significantly larger byte-wise. These points are probably different for every image. A naïve algorithm to solve this would be to simply try to compress all these different dimensions (or in 100px jumps to reduce the search space) and find the points where the byte-size/dimensions ratio is a local minimum. Then choose the most suitable ones as your breakpoints.
    This can be automated, so that authors would have a CLI utility that received the original image and spits out a set of ideal breakpoint images and their corresponding picture element code.

  4. Eric says:

    I’m re-exporting a few years worth of photography for my personal site re-design and have been thinking over these same issues. My initial ideas were:

    Big pictures are great. I want the images (jpegs whose max-width is 100% of a full-width container) to display as big as they possibly can for everybody.
    There’s Moore’s Law so as long as I’m making the fraught assumption that screen size and bandwidth are correlated I may as well assume that they both approximately double along with each other — sending a 750px wide image to a 500px wide window seems about as bad as sending a 3000px wide image to a 2000px wide window, as far as download times are concerned? Maybe? Don’t think to hard about this, it quickly falls apart. But seems truthy to me, still, somehow, if I’m trying to cover as wide a range of resolutions as possible? Can somebody please do some rigorous tests correlating image width to file size and screen size to bandwidth and figure this out for reals?
    320 and up is as good a rule of thumb as any for how-low-do-you-go
    Current hi-end monitors max out at ~3000px but with our march into the (glorious, long-awaited) retina future 4K resolutions and beyond aren’t too far off… a more permanent restriction will be that my old camera was 6MP (3,008 × 2,000) & my new camera is 14MP (4,608 × 3,072).
    I don’t want to have to export more than four versions of any given image because let’s not be ridiculous.

    These thoughts + wanting memorable and nice round numbers lead to me exporting at these max-dimensions: 500, 1000, 2000, [fullsize, up to 4000px]

    But then I got one of those shiny new iPads (2048 × 1536), and, after I got safari to even show me retina quality images (progressive jpg trick), I discovered that when I had it in landscape it was just a hair over my 2000px threshold and would extremely-wastefully load the biggest, 4000px-wide images and proceed to totally choke on them if there were more than one per page… constantly loading and unloading the things into memory such that the experience could best be described as stuttering into voids.

    So I made the (likely short-sighted) decision to optimize for just my device, whilst also thinking some vague thoughts about base two numbers and bayer interpolation (meaning that the extra resolution at fullsize really wasn’t doing me that much good anyways). I’ve settled on these final export points:

    512, 1024, 2048, [fullsize up to 3072 px].

    TL;DR: I spent a lot of time applying very fuzzy thinking to a very hard problem! This stuff is hard! And this is just making the files, never mind all of the stuff about how to actually mark them up in HTML to tell browsers which one to load.

    (A new image format and browsers that handle it intelligently, improbable though these things may seem, can’t come soon enough!)

    • Jason Grigsby says:

      @Eric, This is one of my favorite comments on our blog ever. I’m particularly fond of:


      One minor quibble is that bandwidth hasn’t kept pace with Moore’s Law, but I suspect you may already know that considering all the thought you’ve given this matter.

      Your comment and the thought you’ve put into this perfectly illustrates my point. Thank you so much for taking the time to write it.

  5. Eric says:

    Thanks! After writing it all out and hitting “submit” I thought, boy, I wasn’t thinking very clearly about *any* of this. And I didn’t even spell “led” correctly! But if my confusion is in some way illustrative I guess that’s good.

    A more prescriptive TL;DR might be:

    1) Pick a useful range of resolutions for your image or images.
    2) Devise some system for dividing this range up.
    3) Both of these problems might be harder than you think.

    When picking a range, consider the layout of course, and the current/near-future device landscape. But maybe also, if you’re feeling ambitious, be future-friendly and start by thinking about the *images themselves.* How much information would it ever be useful for any given viewer/browser/layout/screen combination to *ever* have about this image? At what point does the image become too small to be legible or impactful? How can I make this tag a definitive, platonic image resource (like, say, tags are for paragraphs) such that it can efficiently load in ANY layout, in ANY context anywhere on the web, and not simply be a pointer to a file that’s been specially tailored to fit into a single-sized-and-shaped hole?

    That’s going maybe a little overboard… spending a lot of time making and marking up files few browsers will ever request. But if there were some magical image format (.mif) that solved all of our problems and let browsers efficiently load as much or as little data as they needed, I’d be exporting full-size .mif files out of Lightroom without a second thought. (Unless you’re worried about theft & copyright) why wouldn’t you?

    And as for dividing the range… I started with max-width doubling because something something Moore’s Law (oops), and the 2x-ing of retina assets just seems to be in the air. But when the iPad turned out to be the worst-case scenario given my chosen export sizes (loading 10MP images and shrinking them down to fit its 3MP screen!) and I saw how horrible the results of that were, I tweaked my numbers to optimize for the iPad specifically and also tapered the doubling rate at the top end to help the general case.

    This system-for-dividing seems like something we should be able to be a little less wishy-washy about… My files are mostly baked but still I look forward to someone doing some rigorous testing and thinking and handing down some best practices. (:

    • Eric says:

      EDIT, DOH: How can I make this *img* element a definitive, platonic image resource (like, say, *p* elements are for paragraphs)…

  6. Alex says:

    Why not just aim for a certain amount of (mili)seconds to be the max loading time for all platforms and determine what the size should be on tests with that on the different platforms?
    Could even do that without testing, just assume you’d have half of the typical max speed (or around that) of the platform you’re targetting and calculate how long your amount of bytes would take to transfer over that connection. Assuming 3mbit over 3G (since you’ll never get 7.2mbit) that would be 100KB over 375KB/s = 267 ms or 0.267 seconds, add up the latency of the connection (usually around or just under 100ms) and you’ll have the total loading time if the user would load that specific image under optimal conditions server wise.

    So if you want your website to load under 1 second on any connection then you should try to keep your whole page under 1MB for a home connection (10mbit / 8 = 1.25mbyte per second, but you add latency), under 350KB for a 3G user, and under 60KB for a GPRS/EDGE user.

  7. I think the answer may lie somewhere in between what’s been said so far. Design breakpoints yes. Content breakpoints yes…it’s just that images have their own design and content breakpoints.

    I’ve got some sketches kicking around that I should likely turn into an article. I’m not suggesting it will completely answer your question but I think the answer is far less complicated (and at the same time far more variable/difficult to quantify) that we may think.

    As an aside, I think this is also a symptom of the current transition to RWD. We eventually need to get to a point where these techniques are holistic (maybe not the best word…can’t find another right now) rather than rule-based. There is no magic checklist for a lot of this stuff. Designers need to know enough tech to intuitively understand when something will work (or break) and devs need to be more involved with content to better understand the potential/aggregate performance profile of each page/view (and how it will change from device to device).

    Tall order, I know.

    • Jason Grigsby says:

      I can’t wait to see that article! Would love to see what you’re thinking in more detail.

      Quick question. Do you think it is something on an image by image basis or is it something where a common set of image breakpoints would work across a site?

      • Thanks! Hopefully the article will actually make sense :-P

        In regards to your question, I think it would be an 80/20 thing on the majority of web sites (possible exception being advertising micro-sites which are really just a giant carefully art directed canvas so warrant being far fussier). Other sites that could run into issues are those where image size is specifically important to users (eg. Flickr as you recently used in an example) but I think those are few and far between.

        So what we end up with is a scenario where only 20% of images (and often possibly less) require actual art direction and careful alignment of image and content breakpoints. The rest can be sized so that each has a given “scaling viability range”(?). When well planned, this range is often enough to span at least one layout breakpoint. (All of this also operating on the proviso that there are only 2-4 major layout breakpoints…the rest only being minor tweaks primarily related to margin and line length adjustments. Sites with more breakpoints than that are probably micro-managing and will end up with a unrealistically high maintenance burden).

        So while there is no simple rule that everyone can follow, I think (I hope…:-) that this can be explained in a way that is coherent enough that it could form a useful technique. The wild card of course is high density displays but this is almost a separate issue. Sites that (in this day and age) decide to provide double density versions of *all their images* either have very few of them, or obviously don’t care much about bandwidth. The balance of sites will probably 80/20 things once again, opting to only art direct important images (swapping densities is also a form of art direction!).

        And for the rest of the images, the presence of a “scaling viability range” tends to act in their favour. As we know, many responsive sites don’t swap images at all. They also tend to build desktop-down. A side effect of this is that ‘mobile’ layouts benefit from the extra pixels in these larger desktop images. Our approach somewhat mirrors these benefits, but without the excessive file sizes. Because images span breakpoints (and presuming the image ranges are well chosen) they will often load in a “scaled down” state, resulting in crisper content.

        At least… that’s what we’ve found. We’ll see if this still makes sense once I write it up (and a bunch more people try it out)!

        • Regarding that last sentence…”a bunch more people try it out”. I actually just found a nice example today on a large new site (and i’m sure there are lots more…). Will probably use it as an example. :-)

  8. I think defining at what point does a file become an unnecessarily large file for the device is the root of this question. This is a great question as there are so many variables that play into what answer you go with. It’s a question I’ve also thought about far too much.

    To me, the point at which a file becomes an unnecessarily large file for the device, is when the image is wider than screen size. Yet screen size is really tricky to pin point on most mobile devices as James Pearce has noted.
    Though you can tame the beast that is screen size by adding a meta viewport tag and setting the width to device-width and detecting the viewport width.

    So on one hand, you dont want images wider then the viewport, but at the same time, you don’t want to have 20 instances of one image for each popular screen size. I think it’s okay to use a few different images at different ranges and scale them down between break-points. This would mean some devices, you do get images wider than their device-width viewport.

    For example, the viewport witdh on the iPhone in landscape orientation when the width is set to device-width is 480, while on most Android phones in landscape, the viewport width is 533. In this case I would create an image at 533px wide and use it for viewports from 533-480 instead of having an image thats 480px and another at 533px.

    I do think if you are talking about serving different images based on screen size, its beneficial to think about different images for different display densities as well. For example, a medium size image you serve to devices with a “medium” sized screen size, could also double as a high-res version for small screens, granted there was no variation between the two images needed, i.e. art direction.

    Another thing to think about is what is the cost/benefit of switching out images on resize. Is it really worth it to make another call to the server for another image? I think some logic along the lines of checking the viewport width in JavaScript and loading in the image based on this, then check on resize/orientation change if the viewport width has gotten wider, if so, load in your new wider image. If resize/orientation change happens again, check again to see if the viewport width is wider. If it is not, don’t load in a new image and just let the browser scale down you 2nd image you called. This way you should only just have at most typically 2 calls per image or just 1 if the user doesnt resize/cause an orientation change, except for when us web developers come to your website and resize our browsers in Chrome like crazy.

    As I said before, there are so many variables to how this can be approached, but I think the main factor is based on what you said, deciding at what point does a file become an unnecessarily large file for the device. I think this is a really great topic for discussion and it’s been great to read what others have been thinking. There is so much more that could be discussed about this. A few final thoughts though, when thinking about image break-points, mobile devices have a wide range of viewports, even when setting the meta viewport tag to width=device-width. I prefer to think of image sizes as x-small, small, medium, large, x-large, and so on, as opposed to mobile, tablet, desktop. There is so much overlap in viewport sizes between the device classes. Starting mobile-first with image break-points, what size do you recommend starting with Jason? I start with 320px but I know there are devices small then that. Thanks for a great post!

    • Another issue with determining image breakpoints is deciding where the best place is to store that logic.

      You could store it per image like the element does. The issue I see with this, and any other solution that stores other image variations in the element, i.e. data attributes, is that it could lead to maintenance issues if you redesign the site and need new image breakpoints that you didn’t originally have in your tags.

      Another options is to keep image breakpoints in a style-sheet. Jeremy Keith has made a great case for managing breakpoints for CSS and JS in the style-sheet. Jordan Moore also wrote up how this concept could be used for responsive images. I also have some reservations about this method as well. Knowing that image breakpoints don’t necessarily need to fall in line with layout breakpoints, it make me wonder if storing that logic in the style-sheet is the best way to handle image breakpoints.

      Another solution is defining your image breakpoints once in a JavaScript file. Since pretty much all responsive image solutions are JavaScript dependent, it seems like this would be a good place to centralize you logic. This is my preferred solution for image breakpoints when thinking about maintenance.

      There are 3 areas you could store image breakpoint logic, HTML, CSS, or JS. I prefer storing this logic in JS. It seems the easiest place to maintain.

      In the end, it’s a complicated issue with many solutions.

  9. I started to write a lengthy response, even though this post is 10 days old — and knowing the web moves quickly — my thoughts are probably already irrelevant. ;-)

    Here is where you can see my thoughts, if it interests you —

  10. Aeron says:

    RWD design breakpoints are based on screen widths, image breakpoints are based on bandwidth – I really thiink its as simple as that. With the high pixel densities of mobile and now tablet, there’s nothing wrong with serving up oversize desktop images to those devices – if their connection can handle it – they look great. I see this as being similar to those flash video players that will serve up the best quality video your connection can appear to handle. So whatever combination of js, cookies and server-side code you need to do the same for images. I don’t even see this as being exclusive to RWD.

  11. IIPImage says:


    Well, there are of course solutions to this particular part of the puzzle. Image servers can resize and compress dynamically. I’ve put some ideas on how to implement this using the open source IIPImage in a blog post: