Last updated: Aug-15-2023
Cloudinary can help reduce the complexity of maintaining and generating multiple image versions with the dynamic image transformation feature. You can build Cloudinary dynamic image URLs with parameters to scale the image to any size. This means you don't have to pre-create the images, and your images are dynamically resized on the fly as needed.
This is especially useful when using the
<picture> element and the
sizes parameters of the
<img> tag where the browser chooses which of the image versions to display. All of the Cloudinary image URLs that you build can also include any of Cloudinary's image transformation parameters, and the images will be created on the fly if they don't already exist.
fetchpriority="high" to your
<picture> tags if they are the largest or most important images on the page.
You can use the
<img> tag with
sizes to deliver images that are correctly sized for the viewport.
See how the browser loads the larger sized images as the viewport increases:
srcset attribute specifies the different sized images, together with a width descriptor for each. The width descriptor tells the browser what the image's width is, so for example,
256w means 256 pixels. The browser decides which image to load based on the width of the viewport.
Using Cloudinary transformation parameters in the URLs lets you resize the same image on the fly, so you only need one original asset. For example,
c_scale,w_256 delivers an image scaled to 256 pixels.
q_autoalso, to optimize the images.
sizes attribute tells the browser which size of image to use for different page layouts.
For example, the following means if the viewport is at least 50em (50 times the current font size) wide, the image will be 50em wide. Otherwise, the image will be 100vw (100% of the viewport) wide:
Try this responsive demo to see how the browser loads different sized images based on the viewport width.
View the demo code in GitHub.
<picture> element is a wrapper for the
<img> element. It also provides a way to supply alternative
<source> elements, which are visually distinct versions of the image for the browser to display at the specified breakpoints.
See how the image changes based on the viewport width:
<source> element has a
srcset attribute, as described in the previous section, and a
media attribute that specifies the minimum width from which to display one of the images given in the
For example, if the viewport is at least 800 pixels wide, the browser chooses an image from the srcset in this source:
In this case, the image is cropped to an aspect ratio of 2:1 (
ar_2:1), using the fill cropping mode (
c_fill), with the face as the focal point of the crop (
g_crop). It's then scaled down to give two different sizes from which the browser can choose the most appropriate size.
If the viewport is between 600 pixels and 800 pixels wide, a different image is used. This time, it's the full image, just scaled down:
Otherwise, if the viewport is less than 600 pixels, the
srcset in the
<img> tag is used:
In this case, it's a 1:1 thumbnail crop focusing on the face (
Try this responsive demo to see how the browser loads differently cropped images depending on the viewport size.
View the demo code in GitHub.
Having too many image versions reduces the number of CDN cache hits for requested images and increases the average delivery time for images to your users. On the other hand, having too few image versions means delivering images to users that are larger than needed for the available width, and end up being scaled down by the browser. Cloudinary's Responsive Breakpoints Generator is an open source tool that can be used to calculate the optimal number of versions needed for every image that balances the number of image versions generated vs. the file size reduction between each version. The set of breakpoints are thus calculated based on a difference in the actual image file size at different widths.
The Responsive Breakpoints Generator enables you to interactively generate responsive image breakpoints. However, for applications that involve user generated content of images dynamically uploaded to your site, you may want to streamline the breakpoints generation process. You can use Cloudinary's API to upload your images to the cloud and automatically generate breakpoints programmatically:
The upload response includes the URLs you'd need for the image sources:
- Consider including the
responsive_breakpointsparameter in an upload preset, which you can reuse for many images, without having to specify it in every upload request.
- If using an upload preset together with auto-upload you can also set the
notification_urlparameter in the upload preset to handle the returned
breakpointswithin your image workflow.
For more information on requesting breakpoints and possible parameter values, see the responsive breakpoint request settings documentation.