Why Image CDN Pricing Is Broken — And What We Did About It
Credits, transformation units, bandwidth tiers, egress fees. Most image CDN pricing is designed to be confusing. Here's how we decided to do it differently.
A bill you can't understand is a bill you can't budget for
Picture this: you sign up for an image CDN because your site is slow. It works brilliantly. Then the invoice arrives and it's denominated in "credits." You spend twenty minutes trying to figure out whether a credit is a gigabyte of bandwidth, a transformation, or some unholy combination of both.
This is the experience most developers have with image infrastructure pricing. We found it absurd, and we built Spronta to fix it.
The root of the problem
Most image CDN pricing models were designed in a world where vendors wanted to capture value from every type of usage separately:
- Storage: charged per GB stored
- Bandwidth: charged per GB delivered, often with egress fees
- Transformations: charged per image processed (the unit varies by vendor)
- Requests: charged per API call or CDN request
Individually, each charge seems reasonable. Together, they create a system where the cost of a single user viewing a product page with 20 images can be hard to estimate, let alone budget for.
What "credits" really means
Some vendors abstract this complexity into "credits" — a proprietary unit that converts everything into a single number. The problem: you still have to understand the conversion rate. Is a transformation 1 credit? 0.5? Does it depend on file size? Output format?
This isn't transparency. It's the appearance of simplicity layered on top of genuine complexity.
What we did instead
Spronta is priced on two things: storage and bandwidth. That's it.
- You store images. You pay for how much you store.
- Users download images. You pay for how much bandwidth you use.
Transformations are included. WebP conversion is included. Resizing, cropping, blur — all included. We don't charge per transformation because we don't think it's fair to penalise you for serving images correctly.
The trade-off
We're not claiming our model is perfect for every use case. If you transform millions of images but serve very little bandwidth, a per-transformation model might work out cheaper.
But for the vast majority of web applications — where images are transformed once and then served many times from cache — our model is simpler, cheaper, and far easier to budget for.
Why it matters
Predictable costs mean you can build without watching every transform. You can add WebP conversion, add responsive breakpoints, add blur-hash placeholders — without running the numbers first to see if it'll blow the budget.
That's the developer experience we're building for.
Want automatic image optimisation for your app?
Spronta converts, resizes, and delivers images at global scale — with predictable pricing and no credits.
See pricing →