How are transformations counted?

Your account's monthly pricing plan is in part dependent on the total number of transformations performed during a 30-day cycle.

Overview

Transformation counts are impacted by each processing of an asset. The majority of these occur when Cloudinary generates a new 'derived' resource from an asset based on a transformation URL (regardless of the complexity of the transformation).

Your pricing plan is also impacted by storage and bandwidth usage, not covered here.

Transformation counting basics

• Upload processing: The upload of each image and video asset (with or without an incoming transformation) counts as one transformation.

  If you re-upload (overwrite) an asset with the same public ID in the future, that upload is again counted as a transformation.

  Stored raw assets impact your storage quota, but are not counted as transformations.

• Transformation complexity: The count for a single transformation URL is not impacted by the number of transformation parameters in the URL, or the number of transformation components if chained transformations are applied.
• Multiple requests: Since transformations are counted when a new derived asset is generated, multiple requests to the identical transformation URL do not affect transformation counts.

  This includes URLs using Dynamic SEO suffixes, which are resolved on the CDN layer and thus do not increase transformation counts, even if multiple SEO suffixes are delivered with the same transformation URL.

• Default optimizations: Default optimizations count towards your usage, even though the delivery URL does not appear to be different from delivering an original asset. To deliver an original asset without incurring a transformation cost when you have any of the Optimize by default settings enabled, use the original flag (fl_original in URLs).

Based on the above, most images that you deliver result in one transformation for the initial asset upload, and one transformation per image transformation URL delivered (or eagerly generated).

Special transformation counts

The following features or operations address special transformation counting rules.

Progressive videos

Adaptive bitrate streaming

Automatic streaming profile selection (sp_auto)

Manual streaming profile selection

Video AI

Video Player seek thumbnails

Video Player AI highlights graph

Audio

Animated formats

Animated AVIF

Multi-page image files

3D models

AVIF

Effects with special counts

Fetched and remote social media profiles

Custom functions

Additional considerations

URL changes

If two (or more) transformations generate an identical result, but the URL is different in any way, a separate transformed (derived) resource is created (and counted) when each of those transformations is requested.

Examples:

• The transformations are in a different order (w_200,h_200 vs h_200,w_200)
• You use a transformation that has no impact (for example, a_0)
• The same file format is specified in different ways (for example, specifying f_jpg as a transformation parameter vs using the .jpg file extension).
• No file extension is specified, when previously an extension has been specified, even if the same format is returned.

'Auto' transformations

Some 'auto' transformation parameters have the potential to generate multiple derived assets, depending on the browser, device, or viewing size being used when the URL is requested. Each time a new derived asset is generated, it counts as another transformation.

• Automatic format selection delivers images and videos in the optimal format for the requesting browser, so if a transformation URL including f_auto is requested on different types of browsers, that same URL may result in multiple derived assets in different formats.
• Automatic pixel density detection automatically delivers an image using the best DPR for the requesting device. So the single URL may, for example, result in two derived images, one using dpr_1, and one using dpr_2.
• Automatic width selection automatically resizes the image to match the width available for the image in the responsive layout. When you use this parameter, the number of potential derived images depends on the screen or viewport size of the requesting devices and the breakpoints you set. Using this parameter might sometimes result in only two or three different derived images, or in other cases, may result in 20 or more images.

Placeholder images

Placeholder images are used when the requested base image doesn't exist. In that case, if transformations are applied to the placeholder image, and the relevant derived image doesn't already exist, it is generated and counted as a transformation.

Auto-upload

Auto-upload is much like uploading any other file, except that the upload occurs 'lazily' when the URL is first requested.

Thus at the time of the first request, the initial upload counts as a single transformation.

If the auto-upload URL also includes transformations, a derived asset is generated in addition to the uploaded file, resulting in the relevant transformation counts as described in this page.

Eager transformations

You may intentionally generate some 'derived' assets in advance using eager transformations so that they'll be immediately available upon request.

One or more eager transformations can be performed either when uploading an asset (in the upload API method, or through an upload preset), or by using the explicit API method.

Eager transformations are counted identically to on-the-fly transformations. The only difference is that eager transformations are counted when requested via the API call, while on-the-fly transformations are counted when the transformation URL is requested for delivery for the first time.

Console asset editor

When you use the Asset Editor in the Cloudinary Console to experiment with transformations, a new derived asset is generated each time you refresh the preview.

Transformation Builder

When you use the Transformation Builder to preview an image or video with transformations applied, you are not charged for these transformations unless you open the result in a separate browser tab.

Media library operations that delete derived assets

Certain changes to assets via the Media Library, delete any derived assets that specifically depend on those values, and new derived assets are generated when a transformation URL on that asset is requested.

For example, adding/modifying tags may result in regeneration of a conditional transformation with a text overlay that's based on a tag value.

API operations that delete derived assets

Certain Upload API and Admin API operations that change or replace the original asset result in all stored derived assets for that asset being deleted. This means that the next time a corresponding transformation URL is requested, a new derived asset is generated based on the updated asset.

Methods that cause this behavior include: upload, explicit, tags, context, update, delete.

Asset analysis operations on 'Explicit'

When you include parameters that perform special media processing or analyses on existing assets, and return the data in the response as part of an Explicit method call, this extra analysis operation is counted as a transformation.

Specifically, when you run an Explicit method call that includes one or more of the following parameters, that request is counted as a transformation:

• media_metadata(or image_metadata or exif (deprecated) )
• phash
• colors
• faces
• pages
• illustration_score
• quality_analysis
• accessibility_analysis
• cinemagraph_analysis

Add-ons

When using add-ons that are triggered by transformation parameters, then an add-on transformation count is used in addition to the normal transformation count for the derived asset.