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.

Responsive Image Breakpoints Generator, A New Open Source Tool

Responsive websites, even the most modern ones, often struggle with selecting image resolutions that best match the various user devices. They compromise on either the image dimensions or the number of images. We can solve these issues and start calculating image breakpoints more mathematically, rather than haphazardly.

responsive image generator

Further Reading on SmashingMag: Link

The lives of web developers aren’t getting any simpler as the number of different devices and potential screen resolutions increase. The high-resolution arms race seems to be never-ending as vendors try to top one another with innovations in laptop and mobile device screens. New devices such as TVs and smartwatches are entering the market, making the race even more complex.

(View large version6)

To support the wide range of resolutions and devices, a website’s markup must adapt itself to look perfect on all the different devices and in various resolutions, pixel densities and orientations. Managing, manipulating and delivering media — specifically images — is one of the main challenges developers face when building responsive websites.

Implementing a responsive design means building your website where slightly different variants of images will be displayed at various dimensions to save bandwidth and optimize image deliery. While there are several responsive frameworks and responsive image solutions available, they often lack a response to the common need of deciding which image resolutions to select and how many different image versions — responsive image breakpoints7 — to include in your responsive website.

In this article I want to further describe the responsive breakpoints challenge, analyze the mistakes currently being made, and suggest a solution to intelligently find optimal breakpoints for each specific image. This article introduces a new free open source web tool that will allow you to generate breakpoints for your images interactively: the Responsive Breakpoints Generator8.

Common Mistakes Link

Many modern websites are responsive. This means that an image adjusts itself to be displayed in various dimensions. Usually there are different image width limits for each display resolution and each device pixel density — a large widescreen image isn’t very helpful on a small screen, and a small image will not look crisp on widescreen displays. In addition, many responsive layouts involve art direction9, which means that images are not only scaled down, but are also cropped or styled differently for each device, based on its resolution or the browser’s window size.

It seems that most websites still solve this issue in a non-optimal way, either delivering the same high-resolution image to all devices or creating too many different versions for each original image.

Mistake #1: Delivering The Highest Image Resolution To All Users Link

Website owners want their site to look perfect on modern high-resolution devices. Often developers deliver the same hi-res version of each image to everyone: all device resolutions, browser window dimensions and device pixel ratios (DPR). Using this approach, the websites depend on browser-side scaling to fit the images in their responsive layouts.

The websites look great, especially on hi-res displays with high pixel density. However, the same large image files are delivered to devices with much smaller resolutions, resulting in the unnecessary delivery of huge files, which means slower page load times, a negative impact on the user’s experience, and a waste of money on image delivery bandwidth.

For example, take a look at the website for Mango, a popular fashion brand. The following screenshots show a page displayed in a regular laptop’s browser and in standard smartphone resolution.

Mango's Responsive Website (Desktop left, Mobile right)10
Mango’s Responsive Website (Desktop left, Mobile right). (View large version11)

While the responsive site looks fine both on desktop and mobile, there’s a significant bandwidth waste behind the scenes that also affects the website visitor by slowing down the image load time.

The web page image above is delivered in its highest resolution of 1,934×2,048 pixels to all devices. The actual dimensions available in the desktop view above are 700×442, while the mobile view allows dimensions of 200×213 pixels only. This means that a huge 1,934px-wide image is delivered to much smaller displays. This hi-res image weighs 766KB. If you scale it down to exactly 700px wide for the desktop (DPR 1.0), this image would only weigh 119KB, an 84% saving in file size.

If you scale the image down even further to exactly 200px wide (required by the smaller mobile device resolution), the same image weighs only 14KB, reducing file size by 98%, significantly speeding page load time and dramatically saving bandwidth, especially when there are multiple images on each web page.

Another example is, well, Smashing Magazine. Take a look at the two screenshots below of a responsive web page on Smashing’s website, first in a laptop display and second in a mobile device:

Smashing Magazine's Responsive Website (Desktop left, Mobile right)12
Smashing Magazine’s Responsive Website (Desktop left, Mobile right). (View large version13)

The same original image of 500×750 is delivered to all the different device resolutions and browser dimensions. The original image weighs 92.4KB. We can easily decrease file size by reducing the JPEG quality to 80% and further optimizing the image to get a file size of only 66.8KB. But even then, the same image is delivered when the available dimensions are only 356×534 pixels. For the smaller dimensions we could have scaled down the image to exactly 356px wide, to get an optimized JPEG file of 36.2KB, saving 46% of the file size, reducing the bandwidth involved and improving user experience.

Mistake #2: – Creating Too Many Different Image Versions Link

Web developers who want to better match the available display resolutions with the delivered images may create multiple versions for each image. There are frameworks and cloud services (shameless plug: such as Cloudinary14) that simplify this process by dynamically scaling down images for all the different resolutions. This approach ensures that the correct images are delivered to the different devices and displays. The visual quality is great, the user experience is better and no bandwidth waste is involved.

However, matching image dimensions to display resolutions means that developers might need to create dozens, or even hundreds, of different versions for each image. Furthermore, if the responsive design of the website involves art direction aspects, images are displayed in different aspect ratios and styles, and you need to create many different scaled down versions for each one.

Creating so many different images is quite costly: increased image processing CPU time, larger storage space required, and greater image management complexity and costs.

In addition, having too many different image versions significantly reduces the chances of a CDN cache hit. If a user gets tailored image dimensions from your servers, they might be the first user to request this specific image from your CDN layer. An increase in cache misses might mean a negative impact on user experience and an increase in traffic to your origin image servers.

The Breakpoints Selection Challenge Link

To avoid making these mistakes, we’ll need to understand the trade-off between the number of different images, the visual quality and the bandwidth involved. The challenge is to find the best breakpoints for your images.

If scaling down images by a certain level doesn’t significantly save enough bandwidth, you can deliver bigger images to your users and let the browser handle resizing. On the other hand, if a small dimension reduction significantly reduces the file size of the image, you should definitely create another scaled down image version.

The file size reduction when scaling down images varies for different images. It depends on the specific content of your images, which has a different sensitivity to the compression algorithms of JPEG, opt-png, WebP and other image formats. For some images, a small scale-down saves significant file size, while for other images even a more prominent scale-down will not significantly affect it. Therefore, you want to define the file size step where it is worth creating another scaled down image version. Jason Grigsby of Cloud Four15 called this file size step performance budget in his article about image breakpoints16.

What Jason showed, and what was verified by Cloudinary’s analysis, was that different images require a different number of versions to balance the bandwidth reduction trade-off, according to your performance budget.

Consider the following JPEG image:


Assume you need to display this image in your responsive website at various width dimensions between 200 and 1,000 pixels. Define the file size step (performance budget) to be about 20KB. As the table below shows, you only need to create and deliver five different versions of this image to all the different devices and browsers.

No. Width Height File size Image
1 200 133 6.9 KB View image18
2 477 318 27.2 KB View image19
3 681 454 48.0 KB View image20
4 847 565 67.6 KB View image21
5 1,000 667 86.9 KB View image22

Now let’s take another JPEG photo:


Trying to find the best breakpoints for this image using the same settings of 200 to 1,000 pixels wide and about 20KB file size steps, results in this image needing nine different versions as the table below shows.

No. Width Height File size Image
1 200 133 8.7 KB View image24
2 380 253 27.8 KB View image25
3 514 343 48.5 KB View image26
4 619 413 68.3 KB View image27
5 711 474 87.7 KB View image28
6 804 536 108.5 KB View image29
7 883 589 129.3 KB View image30
8 957 638 148.2 KB View image31
9 1,000 667 160.7 KB View image32

As shown above, the number of versions required for one image is almost half of the number required for another one. The difference might be even more dramatic for other kinds of photos. If you multiply this &smtimes;2 difference by millions of user uploaded images, the result is huge savings in storage, image processing costs and image management complexity, while still delivering the best-looking images and preserving the user experience.

A Solution: The Responsive Breakpoints Generator Link

To perfectly balance the number of image versions for your responsive website, we need to find the correct breakpoints according to the file size step (performance budget) that you define. How can you do that? You can generate images for all possible width values and select only the ones that reflect a significant enough file size reduction. However, this is inefficient and can be expensive.

We’ve come up with a new solution for generating responsive image breakpoints. Analyzing the behavior of the compression mechanisms for various image formats (mainly JPEG, opt-png and WebP), we created algorithms to efficiently and intelligently find image breakpoints that match dimensions and file size saving requirements.

This solution is a new free public web tool called the Responsive Image Breakpoints Generator33. I believe you will enjoy trying it out (duh!).

Responsive Breakpoints, an open source tool for responsive images.
Responsive Breakpoints34, an open source tool for responsive images.

The tool allows you to upload your images and define settings to find matching image dimensions and breakpoints that fit your design requirements. As you can see in the screenshot below, you can define the required image width range, the file size step in kilobytes and a safety limit of the maximum number of images you allow. In addition, you can request that the results include double resolution images for DPR 2.0 displays (e.g. Retina display).

Generator settings35
Generator settings. (View large version36)

When you upload an image, the breakpoints are generated according to your settings and are performed automatically in the cloud. The generated breakpoints are displayed in a summary table and are also illustrated on your uploaded image. You can also download all scaled down and optimized images that match the generated breakpoints.

Generated images37
Generated images. (View large version38)

The generator tool generates HTML markup that you can copy and paste into your code. The srcset attribute of the img tag39 is set to list the image versions and width values according to the smartly selected breakpoints. Modern browsers that process img tag will then know how to select the correct image version according to the available space of the image in your responsive web layout. You can also use the tool to create and download a ZIP file of all image files specified in the source set.

 <img sizes="(max-width: 1000px) 100vw, 1000px" 
      srcset="dog_c_scale,w_200-opt.jpg 200w, 
              dog_c_scale,w_508-opt.jpg 508w, 
              dog_c_scale,w_721-opt.jpg 721w, 
              dog_c_scale,w_901-opt.jpg 901w, 
              dog_c_scale,w_1000-opt.jpg 1000w" 
      src="dog_c_scale,w_1000-opt.jpg" alt="A nice dog"> 

As mentioned earlier, responsive layouts involve art direction as well. The original images may need to be cropped to match a different aspect ratio required by the graphic design, for a mobile device for example. The breakpoints generator tool enables you to select multiple aspect ratios. Breakpoints will be generated for each aspect ratio separately, while the original image is cropped to match the required aspect ratio.

Generated images40
Generated images. (View large version41)

You can download all the images of all the aspect ratios together. In addition, the tool generates a HTML5 picture sample code42 that combines the different aspect ratios and their breakpoints into a single responsive HTML solution. Modern browsers, such as Chrome and Firefox, already support the picture element43, while Microsoft’s Edge and Apple’s Safari have recently added support to their new official or beta versions. If you want to support older browsers as well, you can use the Picturefill polyfill JavaScript library44.

  <source media="(max-width: 480px)" 
    sizes="(max-width: 1000px) 100vw, 1000px" 
    srcset="dog_ar_3_4,c_fill__c_scale,w_200-opt.jpg 200w, 
            dog_ar_3_4,c_fill__c_scale,w_386-opt.jpg 386w, 
            dog_ar_3_4,c_fill__c_scale,w_522-opt.jpg 522w, 
            dog_ar_3_4,c_fill__c_scale,w_632-opt.jpg 632w, 
            dog_ar_3_4,c_fill__c_scale,w_739-opt.jpg 739w, 
            dog_ar_3_4,c_fill__c_scale,w_834-opt.jpg 834w, 
            dog_ar_3_4,c_fill__c_scale,w_920-opt.jpg 920w, 
            dog_ar_3_4,c_fill__c_scale,w_1000-opt.jpg 1000w"> 
  <source media="(max-width: 768px)" 
    sizes="(max-width: 1000px) 100vw, 1000px" 
    srcset="dog_ar_16_9,c_fill__c_scale,w_200-opt.jpg 200w, 
            dog_ar_16_9,c_fill__c_scale,w_525-opt.jpg 525w, 
            dog_ar_16_9,c_fill__c_scale,w_746-opt.jpg 746w, 
            dog_ar_16_9,c_fill__c_scale,w_934-opt.jpg 934w, 
            dog_ar_16_9,c_fill__c_scale,w_1000-opt.jpg 1000w">
    sizes="(max-width: 1000px) 100vw, 1000px" 
    srcset="dog_c_scale,w_200-opt.jpg 200w, 
            dog_c_scale,w_508-opt.jpg 508w, 
            dog_c_scale,w_721-opt.jpg 721w, 
            dog_c_scale,w_901-opt.jpg 901w, 
            dog_c_scale,w_1000-opt.jpg 1000w" 
    src="dog_c_scale,w_1000-opt.jpg" alt="A nice dog"> 

The tool is freely available. It’s open sourced under the MIT license and is hosted on GitHub45, while the actual breakpoints generation algorithms and the image resizing and cropping transformations run in the cloud.

Automate Breakpoints Generation Link

The tool allows you to process your images, which is useful if you have a reasonable amount of statically uploaded images. However, what if your web application involves user-generated content of dynamically uploaded images?

To generate breakpoints for images uploaded by users, you need to programmatically generate them from your code. For each uploaded image, you probably need to call an API to generate the breakpoints, store or cache them on your side and then build your HTML5 or CSS snippets according to these breakpoints.

You may want to try out Cloudinary’s API to programmatically request the breakpoints46 for newly uploaded images or existing ones. You can specify settings such as the width range, file size step, maximum number of images and request one or more image transformations to apply on the original image. Such transformations include aspect ratio-based cropping, face detection-based cropping and applying various image effects, filters and optimizations.

You can call the cloud-based API from your development framework code using open source SDKs. For example, the following Node.js code can be used to generate the breakpoints and the matching images for an uploaded image:

  { responsive_breakpoints: 
        create_derived: true, 
        bytes_step: 20000, 
        min_width: 200, 
        max_width: 1000, 
        transformation: { crop: 'fill', aspect_ratio: '16:9', gravity: 'face' }, 
      } }, 
  function(error, result) { console.log(result); }); 

A quite generous free tier (for 75,000 images and 7,500 monthly transformations) is included for running it on your dynamically uploaded images.

Summary Link

I hope the tool will help you address some of the challenges related to responsive images. This complexity is the driving force for new solutions that keep arising, such as the HTML5 picture element and srcset image attribute, the Client-Hints specification47, and plenty of other client-side and server-side solutions.

Whichever responsive design solution or framework you choose, you still need to generate and deliver multiple versions of each image. The challenge of finding the best fitting resolutions, which are the responsive breakpoints for each specific image, is common for all approaches and frameworks.

Depending on the content of images and as a result of the nature of image compression algorithms, you may have to generate more versions for certain images and fewer for others.

Breakpoint generation should be streamlined in your web application when user-uploaded media is involved. Web pages should be rendered dynamically according to the generated breakpoints that allow browsers to download and show images of the best visual quality with optimized file sizes for any device and resolution. These actions will result in reduced bandwidth and processing costs, an improved user experience and an increase in user engagement and conversion rate.


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
  40. 40
  41. 41
  42. 42
  43. 43
  44. 44
  45. 45
  46. 46
  47. 47

↑ Back to top Tweet itShare on Facebook

Nadav Soferman is the CPO and a co-founder of Cloudinary, the leading cloud-based image management service. Nadav is a software developer at his core and has worked at various Internet startups for the past 17 years - developing web & mobile software and managing development teams.

  1. 1

    It’s a fantastic tool … Thanks Smashing Magazine

  2. 2

    Finally, this will save tons of hours optimizing images for responsive websites… Great tool!

  3. 3

    Excellent. Thanks for pointing it out.

  4. 4

    How much did Cloudinary pay you guys to get on here ; )

  5. 6

    great work!

    you know what’s missing? the center point in which the cropping should be done.

    in the example with the dog, the last couple of crops would be around his face, not on the green grass.

  6. 8

    This just feels like we’re heading in the wrong direction. Multiple breakpoints, creating multiple versions of every image on every page? This is far too much work for designers and developers. We need to be smarter than a solution that requires us to constantly recalculate and revise breakpoints, and generate loads of images. Think of the maintenance. The burden should be on the browser and the server to constitute the proper image — not the human.

    • 9

      And what happens if you have to make a small edit to an image? Regenerate all those different versions for all those breakpoints? That’s insane!

    • 10

      Anselm Hannemann

      January 27, 2016 12:40 pm

      Yes, I fully agree with this. However, until we have broader support for Client Hints (see here) or get a responsive image container format itself we will not be able to avoid using great tools like this one.

      @James: Yes, indeed. That is a bummer, it could be automated on the server as well of course but it’s also a big effort to set this up so I pretty much like a simpler tool like this one.

    • 11

      I agree, the browser should recalculate what’s needed in real time, and also, it could be a feature that you can turn on and off. Something like: image optimization -> set breakpoints.

      Good idea!

    • 12

      Agreed, this whole charade screams developmental dead-end, one that will be solved in soon enough as browsers/services develop. We’ll look back on this and laugh, i’m sure of it. Just look at all the practices we had faith in, yet laid to rest as soon as the technology moved on.

      The answer has to be something along the lines of uploading a single image to a CDN/CMS etc. which then creates a myriad of versions, and outputs the correct one as per the conditions.

      This is a job for the technology, not the designer/developer, and i’m struggling to muster the enthusiasm to bother with it beyond basic implementation.

  7. 14

    Just as a FYI, I find the term “image breakpoint” incredibly confusing. I would normally associate the word “breakpoint” with the state of the viewport or the media query one can also set on picture source elements. “Breakpoint” to describe the image size or format itself makes no sense to me.

    I could be wrong though, english is my 2nd language.

  8. 15

    Funny thing about these bandwidth savings is that you need to use larger files on mobile than on desktop due to retina screens.

    So the whole excercise becomes rather pointless.

    • 16

      I often resort to just using a large image with a lot of compression (20-40% quality) for all devices – looks fine when the image is scaled down on retina devices. Can run into performance issues though.

    • 17

      You are right. With 4K screens on 4 inch display dpi is just crazy high on mobile.

      Common misconception is that pixels are not actual pixles on mobile device. In other words if you use 100px in HTML box, actual pixles in that box will be much bigger. For SVG images this is not a problem. For raster images you actually need to server much higher resolution.

      The misconception is so common that even big players like Google serve low resolution images for mobile devices. Those images just look ugly (like they would not fully load or something). For whatever reason Chrome gets better images in image search…

      As bandwidth is getting cheaper (both user and server side) I think it would be wise not downscale images at all whenever image quality is important. E.g. serve low resolution on main page, but on product/article page server high resolution. Always.

  9. 18

    Thank you for this great tool!

    Pedro is absolutely right with his idea about centerpoint.
    I think that it would be ever better if one could modify scaled down images after they have been generated. I mean that you could for example move each generated frame individually to correct position depending on art direction and maybe also scale the original per generated frame. I.e. if for two smallest pictures you only see the nose of the dog, you could select an area from original which is to be shown.
    Yes, of course that changes picture sizes, but that just has to be then solved somehow :) I think it would greatly improve this tool, so it would be worth it.
    But again, great tool!

  10. 19

    Why would I make an hdpi image for something 200px wide if it’s only going to appear on a phone size screen? Why would I not just make a 400px image? It seems like this tool is make more images than it needs to.

  11. 20

    It feels so wrong to generate multiple instances of the same graphic and repeat that procedure for every other graphic. That’s a waste of bandwidth and server space as well as computing and development time. It should be better than that in 2016 (and it could be). Let’s hope this historicically reasoned approach finds an end sometimes.

  12. 21

    Mike (another)

    January 29, 2016 10:46 am

    Tested the tool, while good for breakpoints, the api lacks support for pixel ratio. The “retina button” on the app just doubles the range.

  13. 22

    Interesting article and tool.

    My question is what happens with the image dimensions attributes?

    Google Page Speed and other speed tests still give negative points for images that don’t have width and height set.
    Does the generator add that or how will that work?

  14. 23

    You know, since mobile devices, that are actually being used for the web, tend to have much higher dpi displays than desktop monitors, I usually don’t bother with this. To deliver high quality images to a high dpi screen, you need to serve them a higher than 1x scale anyway. So just keeping the high-res desktop image for mobile devices, and letting the browser scale it down is mostly fine IMO.

    So I’m much more interested in image formats with much higher compression rates at the same quality level, like BPG:

  15. 24

    Cool stuff! Although I confused with crop feature. Is it really exist? I have tried this.

  16. 25

    The privacy statement on does not specify what they do with images. Do they erase them right after generation? Do they store them? Do they sell them? Who owns the uploaded images?

    • 26

      Nadav Soferman

      February 4, 2016 1:12 pm

      All images uploaded to the responsive breakpoints generator tool are available for a few days in order to allow the sample results and delivery URLs to be valid. After a few days, the images are automatically deleted and the cached CDN copies are invalidated. The users are the owners of the uploaded images, they are temporarily stored for usability purposes of the tool and are definitely never being sold.
      If it is not clear from the privacy policy or terms of service, we will let the legal advisors know about it and update the policy accordingly.

  17. 27

    Saying this is open source is like saying Facebook is open source because I can view the frontend code and they have an API.

    I would be extremely interested in seeing these new algorithms that take compression levels into account and predict resulting file size. I’m interested if you’ve developed your own set of Quantization tables to accomplish this. It seems that this is the real magic, but no source code for that is made publicly available. I imagine this would be most useful as a local binary rather than an online API, but then … How do you capitalize on it?

    Trying to capitalize on the “open source” label, is a deceptive and ugly trend.

  18. 28

    The number of different devices available and their potential screen resolutions keep increasing, and to support this wide range of resolutions and devices, responsive website design is now the standard. A website’s markup must adapt itself to look perfect on all the different devices and in various resolutions, pixel densities and mobile device orientations. Managing, manipulating and delivering images, is one of the main challenges of responsive design that web developers face.

    Implementing a responsive design means building your website where the same images may be displayed in various dimensions. One image for all screen resolutions and different devices is not enough. An image per pixel is too much – so how can you automatically choose the optimal responsive image sizes?

    Whether you are using a Javascript based responsive library, the srcset image attribute, the HTML5 element, the modern Client-Hints or other responsive image solutions, they still lack a response to the common need of deciding which image resolutions to select and how many different image versions to include in your responsive website. These are called responsive breakpoints or responsive image breakpoints.

    Cloudinary now offers a solution for intelligently finding the optimal responsive image dimensions for each specific image. The responsive breakpoints generation can be done programmatically using a cloud-based API or interactively using a new free open source web tool – the Responsive Breakpoints Generator.

    Image-specific breakpoints selection

    It’s a challenge to find the best breakpoints for your images, and to avoid making the mistake of not selecting enough images or selecting too many images, you’ll need to understand the trade off between the number of different images, the visual quality and the bandwidth involved.

    When a small dimensional reduction significantly reduces the file size of the image, you should definitely create another scaled down image version. On the other hand, if scaling down images by a certain amount doesn’t significantly save enough bandwidth, you can deliver bigger images to your users and let the browser handle the resizing.

    The challenge of scaling down images is further complicated by the fact that the file size reduction varies for different images. It depends not only on the specific content of the images, but also on the variable sensitivity the image has to the compression algorithms of JPEG, PNG, WebP and other image formats. For some images, a small scale down saves significant file size, while for other images even a more prominent scale down will not significantly affect the file size.

    Therefore, you will want to define the file size step where it is worth creating another scaled down image version. Jason Grigs by of Cloud Four called this file size step performance budget in his article about image breakpoints. Cloudinary’s analysis verified that different images require a different number of versions in order to balance the bandwidth reduction trade-off according to your performance budget.

  19. 29

    Good to know !


↑ Back to top