You Wanted Transformations, You Got a Platform
You need to resize an image, convert it to WebP, and strip the background. Three operations. Should take one API call.
With Cloudinary, that one API call comes bundled with a storage layer you didn’t ask for, a CDN you already have, an asset management dashboard you’ll never open, and a credit-based pricing model that makes cost estimation feel like a word problem. You upload your image to their servers, construct a transformation URL using their proprietary syntax, and hope the monthly bill aligns with your mental model of what “25 credits” means.
Cloudinary is a media management platform. That’s not an insult — it’s a description. If you need upload widgets, DAM features, video transcoding, and a global CDN in one package, Cloudinary does all of that. But if you already have your own storage and CDN — or you’re building a pipeline where images flow through and don’t need to be stored anywhere — you’re paying for infrastructure you don’t use.
The Credit System Problem
Cloudinary bills in credits. One credit equals 1,000 transformations OR 1 GB of managed storage OR 1 GB of CDN bandwidth. These aren’t separate budgets. They share the same pool.
This means a spike in traffic — more bandwidth — eats into the same credits you need for transformations. A backlog of stored assets chips away at credits that could go toward processing. Estimating costs requires you to forecast three independent variables against a shared budget, and hope they don’t collide.
At small scale, this is fine. The free tier gives you 25 credits per month, which sounds generous until you realize that credits are consumed across all three dimensions simultaneously. At scale, the math gets adversarial. You’re running bandwidth projections against transformation volume against storage growth, trying to figure out which limit you’ll hit first.
Compare this to per-request pricing where one transformation costs one price and that’s it. No shared pools, no cross-subsidy between storage and compute. You transform an image, you pay for the transformation.
Proprietary URL Syntax
Every Cloudinary transformation is embedded in a URL:
https://res.cloudinary.com/demo/image/upload/c_fill,w_300,h_300,g_auto/sample.jpg
That c_fill,w_300,h_300,g_auto segment is Cloudinary’s proprietary transformation syntax. It works, but it means every image URL in your codebase — your templates, your CMS, your email system, your API responses — has Cloudinary baked into the string.
Switching away from Cloudinary means rewriting every URL. Not updating a config file. Not swapping an SDK. Rewriting every place you construct or store an image URL. The deeper you go, the harder it gets to leave.
This is lock-in by design. Not through contracts or exclusivity agreements, but through URL structure. Your code and your data become Cloudinary-shaped, and reshaping them is a migration project.
300+ Parameters You Won’t Use
Cloudinary’s transformation reference lists over 300 parameters. Arithmetic operators, conditional transformations, named transformations, chained transformations with slashes, layer-based compositing, text overlays with font parameters, video-specific flags, and delivery hints.
Most developers use maybe 10 of them: resize, crop, format, quality, gravity, and a handful of others. The rest is surface area — documentation to wade through, edge cases to worry about, and ambiguity about which combination of parameters actually does what you want.
A wide parameter space isn’t inherently bad. But when you’re debugging why c_fill gave you a different result than c_lfill with g_auto versus g_auto:subject, the breadth becomes a cost. You’re spending time learning a proprietary DSL instead of shipping the feature.
A Focused Alternative
The Iteration Layer Image Transformation API does one thing: transform images. No storage, no CDN, no asset management. Send an image, define a pipeline of operations, get the result back.
24 operations cover the practical needs of image processing:
- Resize, crop, rotate, flip
- Format conversion (JPEG, PNG, WebP, GIF, AVIF, HEIF)
- Quality adjustment and target-size compression
- Smart crop with AI object detection
- AI upscaling (4x resolution)
- AI background removal
- Color adjustments, blur, sharpen, grayscale
Chain up to 30 operations in a single request. The pipeline executes in order — resize, then remove background, then convert to WebP, then compress to a target file size. Explicit, sequential, predictable.
Here’s what that looks like:
import { IterationLayer } from "iterationlayer";
const client = new IterationLayer({ apiKey: "YOUR_API_KEY" });
const result = await client.transform({
file: { name: "product.jpg", url: "https://example.com/product.jpg" },
operations: [
{ type: "remove_background" },
{ type: "resize", width_in_px: 800, height_in_px: 800, fit: "contain" },
{ type: "convert", format: "webp", quality: 85 },
],
});Three operations, one call, one result. The pipeline is JSON — you can version it in Git, generate it dynamically, validate it with a schema, and read it six months later without consulting a reference guide.
Compare that to Cloudinary’s equivalent:
/e_background_removal/c_pad,w_800,h_800/f_webp,q_85/Both work. One is a proprietary URL segment you need Cloudinary’s docs to decode. The other is a JSON array that reads like what it does.
AI Features Without the Enterprise Tier
Cloudinary offers AI-powered features — background removal, object-aware cropping, generative fill. Some are available on paid plans, others require the Enterprise tier, and pricing varies by feature. Figuring out which AI capabilities are included in your plan requires reading through plan comparison tables and add-on pricing pages.
Iteration Layer includes AI features in every request — same API, same pricing model, no add-ons.
Smart crop uses AI object detection to identify subjects in an image and crop around them. Product photography, profile pictures, thumbnail generation — the crop follows the content, not a fixed center point.
AI upscaling uses AI-powered super resolution to upscale images to 4x resolution. A 200x200 product thumbnail becomes an 800x800 detail shot without the blocky artifacts of naive interpolation. Useful when your source images are lower resolution than your output requirements.
Background removal uses AI segmentation to isolate the foreground subject and remove the background. Clean cutouts for product images, profile photos, or compositing workflows — no manual masking, no green screens.
These aren’t separate APIs or premium tiers. They’re operations in the same pipeline. Chain them with non-AI operations freely: remove the background, upscale to 4x, resize to 1200x1200, convert to WebP. One request.
Compress to Target Size
Here’s a feature Cloudinary doesn’t have: target-size compression.
You need a product image under 500 KB for an email campaign. Or under 150 KB for a mobile app asset. With Cloudinary, you set a quality parameter — q_auto or q_80 — and hope the output meets your size constraint. If it doesn’t, you adjust and try again. There’s no way to say “make this image as good as possible under 500 KB.”
Iteration Layer’s compress_to_size operation takes a file size limit and figures out the optimal quality and dimension tradeoffs automatically:
const result = await client.transform({
file: { name: "hero.jpg", url: "https://example.com/hero.jpg" },
operations: [
{ type: "compress_to_size", max_file_size_in_bytes: 500_000 },
],
});The API iterates through quality levels and, if needed, dimension reductions to hit the target. You get the highest-quality output that fits your constraint. No trial-and-error, no manual quality tuning.
No Lock-In by Design
When you use Iteration Layer, your images live wherever you put them. Your own S3 bucket, your own CDN, your own file system. The API doesn’t store anything — it processes the image and returns the result. If you stop using the API tomorrow, your images are still where they were yesterday.
There’s no proprietary URL format embedded in your codebase. The transformation pipeline is JSON that your application constructs and sends. Swap the API for another service — or for a local processing library — and your templates, your CMS, and your stored URLs don’t change.
This is the difference between a platform and an API. A platform wants to be your infrastructure. An API wants to be a function call.
Side-by-Side
| Capability | Cloudinary | Iteration Layer |
|---|---|---|
| Core model | Media management platform | Image transformation API |
| Storage included | Yes (uses credits) | No — bring your own |
| CDN included | Yes (uses credits) | No — bring your own |
| Pricing model | Shared credit pool (storage + bandwidth + transforms) | Per-request |
| Transformation syntax | Proprietary URL parameters | JSON operation pipeline |
| Operations | 300+ parameters | 24 focused operations |
| Operations per request | Chained via URL segments | Up to 30 per request |
| AI background removal | Paid plans / add-on | Included |
| AI smart crop | Available on some plans | Included |
| AI upscaling | Enterprise / add-on | Included (AI 4x) |
| Target-size compression | Not available | Built-in operation |
| Vendor lock-in risk | High (URL syntax in codebase) | Low (JSON pipeline, no storage) |
| Data residency | US-hosted (default) | EU-hosted (Frankfurt) |
When Cloudinary Makes Sense
Cloudinary isn’t the wrong tool for everyone. If you need a full media management stack — upload handling, asset organization, on-the-fly transformations via CDN, video processing — and you don’t already have infrastructure for storage and delivery, Cloudinary bundles all of that into one service. For teams that want a managed platform rather than building blocks, it’s a reasonable choice.
But if you already have storage. If you already have a CDN. If you’re building a pipeline where images flow through processing steps and land somewhere else. If you want your transformation logic in version-controlled JSON instead of URL strings. Then you don’t need a platform. You need an API.
Get Started
Check the Image Transformation docs for the full operation reference, pipeline examples, and SDK guides. The TypeScript and Python SDKs handle authentication, file handling, and response parsing — your integration is a few lines of code.
Sign up for a free account, no credit card required, and run your images through a pipeline. Compare the developer experience to what you have today.