{"id":21340,"date":"2015-12-22T14:50:02","date_gmt":"2015-12-22T14:50:02","guid":{"rendered":"http:\/\/responsive_images_with_srcset_sizes_and_cloudinary"},"modified":"2025-11-06T15:46:36","modified_gmt":"2025-11-06T23:46:36","slug":"responsive_images_with_srcset_sizes_and_cloudinary","status":"publish","type":"post","link":"https:\/\/cloudinary.com\/blog\/responsive_images_with_srcset_sizes_and_cloudinary","title":{"rendered":"Responsive Images: The `sizes` and `srcset` HTML Image Attributes"},"content":{"rendered":"

Five years ago, Ethan Marcotte [coined the term \u201cresponsive web design\u201d][rwd] and gave it three defining ingredients: fluid grids, flexible media, and media queries.<\/p>\n

An essential part of this flexible media is the use of the srcset img<\/code> attribute in HTML, which plays a crucial role in creating responsive images. The srcset<\/code> attribute, used within the <img><\/code> or <source><\/code> tags, allows authors to define various image resources along with \u201chints\u201d that help the browser determine the most appropriate image source to display based on the resolution and screen size.<\/p>\n

For instance, using srcset<\/code> with descriptors like \u201c2x\u201d and \u201c1x\u201d, as in <source srcset="square-large.jpg 2x, square-small.jpg 1x" \/><\/code>, informs the browser about which image to use for different pixel densities. This setup is particularly beneficial for high-resolution screens, where a \u201c2x\u201d image can provide a crisper and more detailed display.<\/p>\n

This attribute has simplified responsive image sizing, allowing for a more intuitive and efficient process of specifying different image versions for varying display scenarios.<\/p>\n

That second ingredient, \u201cflexible media\u201d turned out to be a bit of a bugbear.<\/p>\n

This is part of a series of articles about Responsive Images<\/a>.<\/p>\n

You see, most of the media on the web is bitmap images. Heck, measured by bytes, [most of the web is bitmap images][http-archive]. And bitmap images are fixed. They have a fixed height and a fixed width, and while it\u2019s possible to make them visually<\/em> grow and shrink using width<\/code> and max-width<\/code> CSS declarations, forcing users on small, low-resolution displays to load enormous images which have been sized to look good on high-resolution displays is a performance disaster. Every time we send a user more pixels than their device can use, we\u2019re asking them to load data which they\u2019ll end up throwing away. We\u2019re sending them waste<\/em>.<\/p>\n

How much waste? Tim Kadlec has estimated that \u2014 for users on low-res mobile devices \u2014 72% of image bytes served up by responsive pages are wasted. Responsive<\/a> pages are sending small-screened users nearly four times<\/em> as much data as they need.<\/p>\n

New markup is here to save the day. We can\u2019t include a single image resource that\u2019ll work for everybody, but by using new responsive image features, we can<\/em> stuff multiple resources into a single <img><\/code> and mark them up in such a way that browsers will load the most appropriate resource out of the set. We can<\/em> mark up image elements which have the ability to adapt<\/em>.<\/p>\n

Let\u2019s dive in with an example: a news-y article page with a single, large-ish image up top:<\/p>\n

https:\/\/ericportis.com\/etc\/cloudinary\/castro-on-the-line\/<\/a><\/strong><\/p>\n

Responsification With sizes<\/code> and srcset<\/code> HTML<\/h2>\n

srcset img<\/code><\/h3>\n

How can we make this image responsive? The first tool in our belt is an <img><\/code> attribute named srcset<\/code>. srcset<\/code> allows us to stuff multiple resources into a single <img><\/code>, via a comma separated list:<\/p>\n

    srcset=\"large.jpg 1024w, medium.jpg 512w, small.jpg 256w\"<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n
We label each resource with a \u201cwidth descriptor\u201d \u2014 those numbers with 'w'<\/code>s after them, above. These let the browser know how wide each resource is. If a resource is 1024 pixels wide, stick a 1024w<\/code> after it in srcset<\/code>.<\/p>\n
\"Image<\/p>\n
Browsers will load the resource that best matches the current context. So, if the image is 512px<\/code> wide on the layout, users on standard screens will probably get medium.jpg<\/code>, and users on HiDPI display will probably get large.jpg<\/code>.<\/p>\n
Why \u201cprobably?\u201d Ultimately, browsers<\/em> decide which users get which resources. And we, as authors, can\u2019t necessarily predict which sorts of users will get what. This is a good thing! Browsers know a lot more about their context than we do. They have a wealth of information about each user\u2019s device, connection, and preferences and the pick-as-you-please philosophy of srcset<\/code> lets them leverage it.<\/p>\n
So, let\u2019s add a srcset<\/code> attribute to an <img><\/code>:<\/p>\n
    <img<\/span> srcset<\/span>=\"small.jpg 256w,\n                 medium.jpg 512w,\n                 large.jpg 1024w\"<\/span>\n         src<\/span>=\"medium.jpg\"<\/span>\n         alt<\/span>=\"It\u2019s responsive!\"<\/span> \/><\/span>\n<\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n
Unfortunately, that won\u2019t quite cut it. When browsers encounter our srcset<\/code>, they\u2019re missing a crucial piece of information: the <img><\/code>\u2018s layout width. In order to know an image\u2019s display dimensions, browsers have to load and parse all of its page\u2019s CSS \u2013 something which usually happens long after srcset<\/code>-parsing. To cope, we need to give the browser an estimate of the layout width of the image right in our markup, using a new attribute: sizes<\/code>.<\/p>\n
sizes<\/code> HTML Tag<\/h3>\n
sizes<\/code> takes CSS lengths. If our <img><\/code> had a fixed width, we could simply stick that width in a sizes<\/code> and call it a day. For instance \u2013 if it was always 640px<\/code> across on the layout, our sizes<\/code> would look like this:<\/p>\n
    sizes=\"640px\"<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n
So our image has two possible sizes. Luckily, just like srcset<\/code>, sizes<\/code> lets us supply multiple values in a comma-separated list. And it lets us tell the browser which lengths to use, when, using media queries. So to give the browser a complete picture of our <img><\/code>\u2019s dynamic layout width, we can mark it up with the following:<\/p>\n
    sizes=\"(min-width: 30em) 30em, 100vw\"<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n
That says, if the viewport is at least 30em<\/code> wide, this image will be 30em<\/code> wide[1]<\/sup>. Otherwise, the image will be 100vw<\/code> wide.<\/p>\n
Putting all of the pieces together, we arrive at the following markup:<\/p>\n
    <img<\/span> srcset<\/span>=\"small.jpg 256w,\n                 medium.jpg 512w,\n                 large.jpg 1024w\"<\/span>\n         sizes<\/span>=\"(max-width: 30em) 30em, 100vw\"<\/span>\n         src<\/span>=\"medium.jpg\"<\/span>\n         alt<\/span>=\"It\u2019s responsive!\"<\/span> \/><\/span>\n<\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n
But! Now we, as authors, have a new problem: creating and managing three resources instead of just one.<\/p>\n
Rendering small, medium, and large versions for our single-image example is a minor inconvenience. But when multiplied by a whole page\u2019s worth of images, this extra work becomes a real burden. Asking poor, mistake-prone humans to render multiple versions of images at specific sizes very carefully and entirely by hand is both cruel and foolish. We need to automate.<\/p>\n
Cloudification<\/h2>\n
Using Cloudinary, we can upload a single, canonical, high-resolution image to the cloud and deliver it in as many different sizes as we want via URL parameters (or Cloudinary\u2019s various SDKs). Controlling our images\u2019 technical characteristics via text and code has enormous benefits:<\/p>\n
This gives us a fluid, adaptable image<\/a>, which will look crisp on large, hi-res displays and<\/em> minimize the number of wasted image bytes sent to users on low-res devices[2]<\/sup>.<\/p>\n
Our example image is a little more complicated. Below its max width of 30em<\/code>, it occupies the full width of the viewport: 100vw<\/code>. Above that max-width, it will always be 30em<\/code> wide (learn about \u2018em\u2019 and \u2018vw\u2019 CSS units<\/a>)<\/p>\n