Cloudinary vs Imgix vs Cloudflare Images: Real Image Delivery Cost for 10 Million AI-Generated Images in 2026
The short answer: Cloudflare Images has two structurally distinct, mutually exclusive billing paths depending on architecture, and mixing them up produces a wrong number. If images are hosted in Cloudflare Images and served through its delivery URL, Cloudflare's own documentation is explicit that optimizing through that URL counts as a delivery, not a transformation — so a 10-million-delivery, 100,000-source-image workload costs only $105/month (storage plus delivery, no separate transformation charge at all). If instead images live on a remote origin (R2, S3, or your own server) and Cloudflare only transforms them on the fly, a different meter applies — Images Transformed, billed per unique source-and-options combination — and the same workload's 500,000 unique variant combinations (100,000 source images × 5 responsive sizes) cost about $250.50/month, including the separate cost of storing the originals in R2. Cloudinary's shared-credit-pool model for a comparable workload totals around $1,080/month — roughly 4 to 10 times more than Cloudflare, depending on which Cloudflare architecture is the fair comparison.
This article is about serving media, not generating it
This comparison covers the cost of storing, transforming, and delivering already-generated images — thumbnails, responsive variants, format conversions, watermarking — for an AI product whose output happens to be images. It does not cover the cost of the generation model itself (a Stable Diffusion-class or similar image model's API or compute cost), which is a separate line item covered elsewhere.
The billing-unit mismatch, up front
Cloudinary and Imgix both bill through a single shared credit currency: one credit equals, interchangeably, 1,000 transformations, 1 GB of storage, 1 GB of delivery bandwidth, or (on Cloudinary specifically) 500 seconds of SD video. Because all three resource types draw from the same prepaid pool, a change in any one of them — a new responsive-image implementation that triples transformation volume, say — consumes the same credits that would otherwise cover delivery bandwidth, even if actual traffic never changed. Cloudflare Images is different in a way that matters even more than "separate meters": it runs two entirely distinct pricing architectures depending on where the images live, and only one of its three named metrics (Stored, Delivered, Transformed) applies to a given image at a time, never all three together.
Cloudflare Images' two architectures, confirmed directly against its own documentation
Path 1: images hosted in Cloudflare Images, served through the delivery URL. Billed on Images Stored ($5 per 100,000 images/month) and Images Delivered ($1 per 100,000 images/month) only. Cloudflare's own pricing documentation states this explicitly: "When you optimize a hosted image through the image delivery URL, this counts toward Images Delivered — not Images Transformed." Requesting five different sizes of the same hosted image does not generate five transformation charges; each request is simply a delivery, billed at the flat $1/100,000 rate regardless of which size or format variant was requested.
Path 2: images stored on a remote origin (R2, S3, your own server), transformed by Cloudflare on the fly. Billed on Images Transformed only — the first 5,000 unique transformations/month free, then $0.50 per 1,000 unique source-image-and-options combinations. Storage and delivery for these remote-origin images are not billed through Cloudflare Images at all; they're billed under whatever service actually holds the originals (R2's own storage rate, for instance). A worked example from Cloudflare's own documentation: serving 2,000 remote images in five different sizes produces 10,000 unique transformations — the count is driven by unique (image × size/format) combinations, not by how many times each is subsequently served.
A third path exists for completeness: the Images binding in Workers, where every call counts as a transformation regardless of whether the image or parameters are unique — a different, more expensive-at-volume mechanic than the URL-based remote-transform path, relevant only to a Workers-code-driven integration rather than a standard delivery-URL setup.
What each vendor bills
Cloudinary (OFFICIAL, cloudinary.com/pricing, checked July 2026). 1 credit = 1,000 transformations, OR 1 GB of managed storage, OR 1 GB of net delivery bandwidth, OR 500 seconds of SD video. Plus: $89/month. Advanced: $224/month, each with an included monthly credit allocation (exact credit counts vary by plan and are not fully itemized on the public pricing page). At a typical blended rate, paid-plan credits cost roughly $0.40 each — meaning delivery bandwidth, priced through this shared currency, works out to roughly $0.40/GB, several times a raw CDN's direct bandwidth rate. Video transformations consume credits 2–4x faster than image transformations, a real cost multiplier for any product mixing image and video media through the same account.
Imgix (OFFICIAL, imgix.com/pricing). Also a shared, three-category credit pool — media management, delivery, and transformation — drawn from one prepaid allocation per billing period, with 1 credit per GB for delivery bandwidth. Overage credits are priced at 120% of the plan's standard per-credit rate, and once that overage allowance is itself exhausted, Imgix blocks further image requests entirely rather than continuing to serve them silently — a real availability risk, not just a cost one. Imgix's exact dollar-per-credit rate across tiers is not published precisely enough to produce a confident total dollar figure for this article's workload; the structural risk (cross-category credit depletion, 120% overage penalty, hard service cutoff) is the more important finding than a specific number.
Cloudflare Images (OFFICIAL, developers.cloudflare.com/images/pricing). Free: 5,000 unique transformations/month (applies to the remote-origin transform path). Three independently-named metrics that apply depending on architecture, as described above: Images Transformed: $0.50 per 1,000 unique combinations (remote-origin path only). Images Stored: $5 per 100,000 images (hosted path only). Images Delivered: $1 per 100,000 images (hosted path only).
Normalizing the workload, under each architecture
All ILLUSTRATIVE. This article models 100,000 source images, each generating 5 responsive variants, delivered 10 million times a month in total (a 2 MB average source size for the Path 2 origin-storage calculation).
Under Path 1 (hosted in Images, delivered via URL): the relevant meters are 100,000 stored images and 10 million total deliveries — variant count and cache behavior don't change the bill, since every delivery, repeat or not, bills the same flat rate.
Under Path 2 (remote origin, transform-on-the-fly): the relevant meter is unique transformation combinations — 100,000 source images × 5 variants = 500,000 unique combinations — with delivery count being irrelevant to the Cloudflare bill, since repeat deliveries of an already-computed remote-transform variant aren't billed through Images Delivered at all in this path.
Cost at this workload, by architecture
Formula: Path 1 = (stored images ÷ 100,000 × $5) + (total deliveries ÷ 100,000 × $1); Path 2 = (max(0, unique combinations − 5,000) ÷ 1,000 × $0.50) + separate R2 storage cost for the originals; Cloudinary = total credits × ~$0.40/credit, summing bandwidth, transformations, and storage into one pool.
| Platform / path | Basis | Monthly cost |
|---|---|---|
| Cloudflare Images, Path 1 (hosted, delivery URL) | $5 (100K stored) + $100 (10M delivered) | $105.00 |
| Cloudflare Images, Path 2 (remote origin, transform-on-the-fly) | $247.50 (495,000 billable unique transforms, 5,000 free) + ~$3.00 (R2 storage for 100K × 2MB originals) | ~$250.50 |
| Cloudinary | 2,000 credits (bandwidth: 10M × 200KB ≈ 2,000 GB) + 500 credits (transforms, treated per-unique-combination) + 200 credits (storage: 100K × 2MB ≈ 200GB) = 2,700 credits × ~$0.40 | $1,080 |
| Imgix | Same general shape as Cloudinary (shared credit pool, 1 credit/GB delivery); exact dollar-per-credit rate not published precisely enough for a confident total | Structurally similar to Cloudinary; confirm exact rate via Imgix's own calculator |
At this specific workload, Cloudflare's hosted-and-delivered Path 1 is the cheapest option by a wide margin — about 10x cheaper than Cloudinary — precisely because it has no per-variant transformation charge at all once images are hosted in Cloudflare Images. Path 2 is still substantially cheaper than Cloudinary (roughly 4x), but meaningfully more expensive than Path 1 for this specific workload shape, since every one of the 500,000 unique source-and-size combinations is billed once regardless of how many times it's later served.
Why the architecture choice matters more than the vendor choice, on Cloudflare specifically
Formula: Path 1 cost scales with delivery volume and stored-image count; Path 2 cost scales with unique transformation combinations, independent of how many times each is served. For a workload with many repeat deliveries of a small set of variants (a product catalog, user avatars, or any image served to many users), Path 1's flat per-delivery rate is the better fit, since it never multiplies by variant count. For a workload generating many genuinely unique, rarely-repeated images — closer to the shape some AI image-generation products actually produce, where each user's output may be seen only once — Path 2's per-unique-combination charge could, at a high enough variant count per image, approach or exceed Path 1's cost, though in this article's specific 5-variant workload Path 1 still wins by more than 2x.
Sensitivity
- Which Cloudflare architecture applies. The single largest lever in this comparison on the Cloudflare side; Path 1 and Path 2 differ by more than 2x at this article's workload, and the gap moves further depending on variant count and delivery-to-unique-image ratio.
- Number of responsive variants per source image. Directly multiplies Path 2's unique-transformation count and Cloudinary's transformation-credit consumption; has no effect on Path 1's delivery-based billing.
- Delivery count relative to unique image count. A high ratio (many repeat deliveries per unique image) favors Path 1 strongly; a low ratio (mostly one-off images) narrows or could reverse the gap between Path 1 and Path 2.
- Video content mixed into the same account, on Cloudinary specifically. Burns credits 2–4x faster than images, directly inflating the shared pool's consumption rate for any product combining both media types.
Budgeting traps
- Mixing Cloudflare's two architectures into one invoice. Images Stored and Images Delivered apply to images hosted in Cloudflare Images; Images Transformed applies to remote-origin images transformed on the fly. They don't stack for the same image.
- Assuming a hosted image's variant count adds transformation charges. It does not, on the delivery-URL path — every variant request bills as a delivery, not a transformation, regardless of how many distinct sizes or formats are requested.
- Estimating Cloudinary's or Imgix's cost from bandwidth alone. Transformations and storage draw from the same shared pool; underestimating either can exhaust credits meant for bandwidth even if traffic forecasts were accurate.
- Ignoring Imgix's hard service cutoff once overage credits are exhausted. Unlike a vendor that simply bills more, Imgix stops serving images entirely past that point — a real availability risk, not just a cost one.
What to ask before you buy
Decide up front whether your images will be hosted in Cloudflare Images or live on a remote origin like R2, since the two paths bill on entirely different meters and this article's workload shows roughly a 2.4x cost difference between them. Ask Imgix directly for its current per-credit dollar rate at your expected tier, since no public source gives a precise enough figure to compute a confident total cost at volume.