Cloudinary's credit system is a massive trap for anyone running
The math behind the credit system
Cloudinary doesn't just charge you for storage or bandwidth; they use a unified credit system. In 2026, the math stays consistent: one credit is equivalent to any of the following:
- 1 GB of managed storage
- 1 GB of net viewing bandwidth
- 1,000 transformations
The issue isn't the storage or the bandwidth—it's the transformations. Every time your code requests a resize, a crop, a format conversion (like moving from PNG to WebP), or an overlay, you are burning through those credits.
For a small landing page with static assets, the Free tier’s 25 credits are plenty. However, if you are building a modern web app using next/image with Cloudinary’s f_auto,q_auto pipeline, you are essentially telling the server to generate different versions of every image for every device breakpoint. If a search engine bot crawls your site aggressively, you can burn through those 25 credits in a single afternoon.
Breaking down the actual costs
Since I've been benchmarking different media CDNs, I've noticed a massive jump in cost once you move past the hobbyist stage. Here is how the tiers actually shake out:
- Free Plan ($0): 25 credits included. The danger here is that there is no overage billing. If you hit your limit, your images stop transforming or delivering entirely. It's a hard cutoff that can break your UI.
- Plus Plan ($89/month): 225 credits. This is the "sweet spot" for most small agencies. It handles roughly 225,000 transformations. If you're running a 100-page site with multiple breakpoints per image, this is your baseline.
- Advanced Plan ($224/month): 600 credits. You really only need this if you want the AI-driven background removal or heavy video transcoding features.
- Enterprise: Custom pricing. This is for when you need an SLA, SSO, or dedicated infrastructure.
Why your credits are disappearing faster than expected
I've seen several developers go into a panic when their monthly bill spikes. Usually, it comes down to three specific technical mistakes in their AI workflow or deployment strategy:
1. Eager Transformations: The Cloudinary dashboard often suggests "eager" transformations. This means the moment you upload an image, the server pre-generates every single size and format you've defined. You are paying for those transformations immediately, even if no user ever actually views those specific versions.
2. The Cache Key Trap: Cloudinary caches transformed URLs, but the cache is highly sensitive. If your CMS (like Sanity) passes slightly different crop coordinates or gravity parameters (g_auto) for every single request, Cloudinary treats each one as a brand-new transformation. You aren't hitting the cache; you're hitting the billing engine.
3. Video Weight: Video is the silent killer. Using q_auto or f_auto on video assets is much more "expensive" in terms of processing weight than simple image resizing. If your project shifts from a photo gallery to a video-heavy feed, you will need to jump to the Advanced tier almost immediately.
If you're setting this up from scratch, my advice is to be extremely disciplined with your transformation parameters. Don't let your code generate infinite variations of the same asset, or you'll be looking at an $89 upgrade before your first month is even over.