Cloudinary credits: transformations count variants, not visitors

You are about to send social traffic to an image-heavy landing page, and the media CDN behind it meters usage in credits. The worry is that every visitor triggers a fresh resize and the meter runs away. Cloudinary’s published rules say otherwise. This piece reads them as documented on 21 September 2026 and does the arithmetic with numbers you can replace.

One credit, four meters

Cloudinary’s pricing page defines one credit as any one of: 1,000 transformations, 1 GB of managed storage, 1 GB of image bandwidth, or 2 GB of video bandwidth. The video line is marked “paid plans only”. Credits can be mixed and matched across these resources up to the plan’s monthly limit.

PlanMonthly toggleYearly toggleMonthly creditsPool as transformations alone (arithmetic)
Free$0$02525,000
Plus$99 per month$89 per month225225,000
Advanced$249 per month$224 per month600600,000
EnterpriseCustomCustomNo published numberNot applicable

Prices are as listed on 21 September 2026. The two price columns are the page’s Monthly and Yearly toggles, not two versions of one figure. The last column is arithmetic from the credit definition, not a promise about any real workload, since the same credits also pay for storage and bandwidth.

Some paid accounts are measured in image impressions instead of image bandwidth, at 1 credit for 20,000 impressions per Cloudinary’s image impressions FAQ. Check your account to see which applies.

Counted when a variant is generated, not when it is delivered

A common assumption is that every resize or reformat is billed again on every view. That is not what Cloudinary documents. Its transformation-counts page says transformations are counted when a new derived asset is generated, so multiple requests to the identical transformation URL do not affect the count. One hero URL served to a large crowd is one transformation, plus that many deliveries.

Complexity does not change it either. The count for a single URL is not affected by how many parameters it carries or how many chained components it has. A crop, a resize and a quality setting in one URL still count as one.

Two more rules apply. Each upload counts as one transformation, and re-uploading the same public ID counts again. And default optimizations count even though the delivery URL looks like the original. With any Optimize by default setting on, the docs give fl_original as the way to deliver an untouched original without the charge.

The premise that each visit re-bills the resize does not match what the vendor documents.

Where a responsive page does multiply them

The multiplication comes from the number of distinct URLs generated, and the “auto” parameters are where it grows. Cloudinary’s own list names three that can produce several derived assets from one URL:

  • f_auto delivers different formats to different browsers, so one URL can yield several formats.
  • Automatic pixel density can, for example, yield one dpr_1 asset and one dpr_2 asset.
  • Automatic width depends on the requesting screens and the breakpoints you set. The doc says it may yield only two or three derived images, or 20 or more.

Cloudinary’s client hints documentation limits this. DPR values are rounded up to the nearest integer specifically to avoid creating extra derived images, so 1.5 is served as 2.0. Width is rounded up in steps of 100 pixels by default.

A hypothetical, not a measurement: a hero image’s breakpoints produce 20 widths, delivered in 2 formats at 2 pixel densities.

  1. 20 widths times 2 formats is 40 variants.
  2. 40 variants times 2 densities is 80 derived assets, counted once each.
  3. Ten such images is 800 transformations, plus 10 for the uploads.
  4. 800 transformations is 0.8 of a credit, against the Free plan’s 25.

That holds only if the three vary freely and every combination is requested. Substitute your own breakpoints, formats and image count.

The docs also flag a trap unrelated to visitors. If two transformations generate an identical result but the URL differs in any way, each is a separate derived asset and is counted separately. The page’s examples: w_200,h_200 against h_200,w_200, f_jpg against a .jpg extension, and a no-op such as a_0. Two people writing the same URL two ways double the count.

The honest conclusion: the transformation line for a typical hero-image page is small. It grows with variants and with new assets, not with the crowd.

When one variant costs more than one

The exception is a page using operations with special counts. From the same page:

  • AVIF derived images under 2 MP count 1. Larger ones count 1 plus 1 per 2 MP or part.
  • Animated images (not AVIF) count 1 plus 0.1 per frame.
  • Progressive H.264 video counts 2 per second for derived SD and 4 per second for derived HD, with parts of a second rounded up.
  • Adaptive streaming with sp_auto counts 8 per second up to 1080p.

Some effects add a count on top of the standard image count: background removal 75, generative fill 50, enhance 100, generative background replace 230.

One 30-second derived HD progressive video at 4 per second is 120 transformations. One background removal is 75, so 1,000 of them is 75,000, three times the 25,000 the Free plan’s pool would be worth as transformations alone.

The docs offer a baseline tip. Save the expensive step as a named transformation and use it as the baseline (bl_) in each URL, and you are charged once for it across several sizes. Add-ons are billed separately from credits and are outside this piece.

The meter a visitor does drive

Bandwidth is what a crowd moves. For images it is based on delivered file size, at 1 GB per credit. Hypothetically, if a page’s images total 2 MB per view, 25 GB (taking 1 GB as 1,000 MB) is roughly 12,500 views, before any other meter draws on the same 25 credits. Replace 2 MB with your measured page weight.

For video, the credits FAQ says 1 GB generally comes to about 500 seconds of delivered SD or about 250 seconds of HD. The pricing page separately lists 2 GB of video bandwidth per credit, paid plans only. Both are reported as published, not reconciled.

Storage moves too. It includes the main asset, a cached copy of each derived asset, and backups, so a heavily responsive page grows it. It is a current total that falls when assets are deleted. On pricing models, see how storage is priced by seat, by terabyte, or by asset.

Transformations and bandwidth are measured over a rolling 30-day window, not a calendar reset. The FAQ’s example: a Free plan user runs a batch using 10 of 25 credits on Day 1. Those 10 count every day until Day 31, when they drop out. A spike ages out without action, but one big week sits in the total for a month. The same pattern appears in free session recorders and the spike that empties the quota.

The pages read for this piece do not say what happens when an account passes its allowance. Confirm that with Cloudinary before the campaign.

Before the campaign page goes live

  • Count distinct URLs per asset, not visitors. The Media Library’s Derived Assets tab shows an asset’s derived versions so you can reuse them.
  • Fix one canonical URL form, one parameter order and one way of stating the format.
  • Choose the breakpoint count for automatic width deliberately, since the docs tie derived images to the breakpoints set.
  • Keep expensive effects and per-second video derivations off the hot path unless needed, and use fl_original where an untouched original is intended.
  • Set the usage notification emails the docs describe, and read the dashboard breakdown Cloudinary calculates automatically.
  • The vendor states the Free plan can be used in production while the 30-day allowance is not exceeded. Treat that as Cloudinary’s claim.

The same reader moment appears in the page a social campaign actually sends traffic to.

How this was checked, and what it is not

Cloudinary’s plan prices, credit definition and counting rules were read from the vendor’s own pricing and documentation pages on 21 September 2026, listed under Sources. Prices verified 21 September 2026. This is not Watchdog data and is not on the re-verification schedule, so the figures can go stale.

Cloudinary is the worked example because it publishes its counting rules. Other image and video CDNs meter differently, and this piece does not survey or rank them.

followedapp is published by the team behind RecurPost, and RecurPost is one of the vendors covered under the same rules as every other.

FAQ

Is a transformation billed every time someone loads the image?

No. Per Cloudinary’s transformation-counts page, the count rises when a new derived asset is generated, and repeat requests for the identical URL do not add to it. Delivery still consumes bandwidth.

What does a visitor actually cost in credits?

Delivered bandwidth, at 1 GB per credit for images, or impressions on accounts using that metric. As a hypothetical, a 2 MB page view uses about 1 credit per 500 views, so replace 2 MB with your own measured page weight.

Sources

Scroll to Top