Battle of the Transformers: Which image service gets to handle your image payload?

With the recent release of the Gumlet transformer, Imager now have first-party support for eight different image transform services; Imgix, ImageKit, ImageBoss, Bunny.net, AWS Serverless Image Handler (now called "Dynamic Image Transformation for Amazon CloudFront" 😰), Craft Cloud, Cloudflare Images, and... Gumlet.

Imager’s transformer concept makes it easy to switch between image transformation services. But which one should you choose? In this roundup, we’ll look at what each service offers, how they’re priced (a key factor), and how well they align with the workflow and features you're used to in Imager and Craft CMS.

But first, let's look at what a transformer does.

The what and how behind Imager's transformers

A transformer in Imager is the component responsible for actually generating the transformed image requested by your code. It’s the heart of what Imager does.

The built-in craft transformer is a beast that uses either GD or Imagick, along with their (frustratingly arcane and obscure) features, to handle image transformations. It also run post-optimisations, saves the final image to disk and, if configured, uploads it to an external storage.

In contrast, the transformers for external services is much simpler. Most of the time, they just generate a custom URL that creates the image on-the-fly when it’s requested.

With the exception of the built-in imgix transformer, all other transformers are separate (free) plugins that you install in Craft alongside Imager. Each transformer comes with its own config file, where you'll need to define the necessary settings. To tell Imager which transformer to use, simply set the transformer setting in Imager’s main config file.

You can also overwrite what transformer to use in your template code, and there is a separate transformerParams transform parameter that is used to send custom params directly through to the transformer:

In theory, and in many scenarios, this is all you need to swap out your existing transformer with another. Unfortunately, since the feature set of these services differ, there may be more to it depending on your project. Let's dive into some of those challenges.

Considerations when moving to a new transformer

None of the services we're looking at has all the functionality that Imager provides when using the craft transformer (it's not even close). And some have features that the craft transformer doesn't have, and that is difficult/impractical to replicate on a stand-alone server. If all you do in your project is to resize and optimize (Craft) assets, and deliver them in different formats, though – all the services will do that.

In general, basic transform parameters like width, height, aspect ratio, mode, format, quality, etc, will be automatically translated by all the transformers. But, in general, no special parameters like effects, watermarks, etc, will be. For those, you need to manually translate them into the equivalent feature in the service, using the transformerParams parameter, see example below:

A huge benefit of using a dedicated service, is that all of these services can deliver modern image formats, ie webp and/or avif, automatically to users with browser that supports it (which in 2026 is the vast majority). For most of the transformers this is most easily enabled through their config (for instance using defaultParams which many of them have), or through the format transform parameter. One important thing to consider, is that most of the transformers will allow you to override the auto format, by actually specifying a specific format in your template code. So if you previously diligently specified format as part of the transform, you can probably remove that.

Another big benefit, and arguably the largest, is that transforms are offloaded from your server to an external server, freeing up alot of compute. Image transformation is by far the most resource hungry thing most Craft sites ever do, and it's the kind of load that arrives in bursts; a bulk re-save, a big import, or an editor dragging forty 24 megapixel photos into an asset field on a Friday afternoon. That's awkward to plan capacity for, and it's the reason a lot of otherwise modest sites are running on servers that are two sizes too big. Offload it, and you get to size your server for serving pages, which is what it's actually good at.

The side benefits are worth having too; no transformed images filling up your disk, no cache folder that slowly becomes a problem nobody wants to own, and no more evenings spent working out whether Imagick was compiled with the right delegates.

Two camps

Once you line the eight up next to each other, they sort themselves into two fairly distinct groups. It's a useful split to have in your head before you get into the details of any single one, because the two camps really want you to ask different questions.

CDN-first transformers

Bunny.net, Cloudflare Images, Craft Cloud and, with an asterisk, AWS Dynamic Image Transformation for CloudFront.

For these, image transformation isn't really the product. The product is delivery, and transformation is a feature bolted onto the edge of a network you're already paying for. The parameter sets reflect that: resize, fit/crop mode, quality, format, and a modest handful of adjustments like sharpen or blur. There's no asset management, no image-specific dashboard to speak of, and mostly no content-aware cropping (Cloudflare's automatic gravity being a partial exception).

That sounds like a list of shortcomings, but for a lot of projects it's exactly the right shape. If your templates only ever ask for a width, a ratio and a format, everything above that is surface area you're paying for and not using. Pricing tends to follow the same logic; it's bundled into bandwidth, or it's a flat add-on, or in Craft Cloud's case it's simply part of the hosting you already bought.

AWS is the odd one out here, and gets an asterisk because it isn't a service so much as a stack you deploy yourself. Under the hood it's sharp, so the raw capability is genuinely broader than the other three in this camp. But there's no product wrapped around it. No dashboard, no support, no image management, and the operational burden is yours. It belongs in this camp not because it's limited, but because you're the one building the platform, and your costs are AWS costs rather than a subscription.

Full-featured image services

Imgix, ImageKit, Gumlet and ImageBoss.

These are purpose-built image products, and it shows. Deep parameter sets, content-aware cropping and face detection, text and image overlays, watermarking, colour and effect operations, and in Imgix's, ImageKit's and Gumlet's case a whole platform around it; asset management, analytics, video.

This is the camp to look at if any of the more interesting things the craft transformer does are load-bearing in your project, because it's where you'll find equivalents, and a fair few things the craft transformer can't do at all. It's also where transformerParams stops being an escape hatch and starts being a normal part of how you write templates.

Broadly: ImageBoss is the lightest and most approachable of the four, Imgix is the most parameter-rich and the one with the longest history behind it, and ImageKit leans hardest into being a platform, with DAM and AI features layered on top of the transformation engine.

Gumlet sits close to ImageKit in scope, with smart cropping and face detection, background removal and upscaling, and a video side to the business as well. Two things make it interesting for the argument this article has been making. It handles auto-format negotiation across WebP, AVIF and JPEG XL, which is the widest format coverage of anything here. And it does network-aware compression, adjusting how hard it compresses based on the connection at the other end, which is the sort of thing you simply cannot replicate on your own server no matter how many optimizers you bolt on.

Which camp are you in?

The fastest way to find out is to open your templates and look at what you actually pass to transformImage(). If it's width, height, mode or ratio, and occasionally format and quality, then you're a CDN-first project, and you should be choosing on price and on which network you're already using rather than on feature lists. If instead you see focal points, watermarks, effects, or you find yourself reading a service's parameter reference before you've even installed the plugin, you want camp two.

The second question is about the shape of your pricing, and it's the one people get wrong most often. The two camps don't split neatly along billing lines, so you can't shortcut this one; you have to look at each service. But the underlying question is always the same. Does your bill scale with how many images you have, or with how many times they get served? Those two numbers are wildly different for most projects, and picking a service that meters the one you have a lot of is how you end up with a bill nobody budgeted for.

Which brings us to the part everyone actually wants to know about.

How they're priced

There are eight services here and, near enough, eight billing models. That's not laziness on the vendors' part, it's the market being genuinely unsettled about what the unit of value is. So rather than a table of headline prices, which would be obsolete by the time you read this, here's what each one actually meters.

Bunny.net is the simplest to reason about. The Optimizer is a flat $9.50 a month per website, and it covers unlimited requests, unlimited optimizations and unlimited images processed. CDN bandwidth is billed separately on top, starting around $0.01/GB for Europe and North America and rising for Asia-Pacific and South America. There's no transformation meter at all, which means no surprises. The catch is that it's billed per pull zone, so an agency running five client sites on five different origins is paying five times over.

Cloudflare Images meters unique transformations. The free plan covers 5,000 unique transformations a month, and beyond that it's $0.50 per 1,000. Two details matter more than the headline number. First, "unique" resets monthly, so this is a recurring cost per variant, not a one-off. Second, and this is a genuinely nice bit of design, a transformation using format=auto counts once even though it's served as AVIF to some users and WebP to others. Format negotiation is free. Breakpoints are not.

Craft Cloud doesn't meter transforms at all. They're part of the platform, bundled into what you're already paying for hosting, alongside static caching and a CDN for static and front-end assets. If you're on Cloud already, the transformer is effectively free and this whole section is moot for you.

AWS is the one where you're buying raw infrastructure rather than a product, so the numbers look different in kind. AWS's own estimate for the solution running with default settings in us-east-1 is roughly $5.30 a month for 100,000 new images, $22.51 for a million new images, and $7.65 for a million cached ones. Cheap at scale, and the reason people reach for it. Just remember that none of that covers your time when the Lambda starts timing out on someone's 60 megapixel TIFF.

Gumlet bills purely for CDN bandwidth delivered, and is unusually blunt about it; there are no charges or limits on the number of original images or the number of optimizations performed. You pay for what goes out the door and nothing else. The plan tiers are bandwidth allowances with per-GB overage beyond them, and the overage rate drops as the tiers go up. Check the current tiers before you budget, because Gumlet has restructured its pricing more than once.

ImageBoss bills per origin image, or "master image" in their terminology, with unlimited derivatives from each. The minimum is $5 a month, which includes 4,200 master images and 5GB of transfer, and only images actually requested during the period count toward that. Beyond the base it's per 1,000 active images, bandwidth over the allowance runs $0.10/GB, and a custom domain is a $20/month add-on. That "active" qualifier is unusually generous; a big dormant archive costs you nothing until someone looks at it.

ImageKit meters bandwidth, and transformation count doesn't enter into it. The free tier is 20GB of bandwidth a month, Lite is $9 with 40GB included and $0.50/GB after, and Pro is $89 with 225GB included and $0.45/GB after. Generate as many variants as you like; you pay for what gets delivered. One thing to check before you commit, given everything above about modern formats: automatic AVIF is listed as available on demand on the Pro plan and above, not on Free or Lite.

Imgix has moved to a credit system, and if you last looked at their pricing a few years ago it will not be the model you remember. Everything now draws from a single pool of credits shared across media management, delivery and transformation. Bandwidth and cache reads cost one credit per GB, image cache storage costs two credits per GB per month, and visual edits vary by feature. Bundles run from $150/month for 830 credits at $0.18 each up to $500/month for 3,570 credits at $0.14, with the per-credit rate falling as you commit to more. Exceed your bundle and you don't get cut off, you get charged overage rates that are priced higher per credit than the bundled ones. Imgix's stated reason for the change is that the old origin-images model made it awkward to offer newer video and AI capabilities consistently across customers. It's a more flexible model, but it's also harder to forecast, and it's now the most expensive entry point of the eight by a wide margin.

What this means in practice

Line those up and the pattern is clearer than the individual numbers suggest.

If your bill should not care how much traffic you get, you want Bunny or ImageBoss. If it should not care how many images you have, you want ImageKit or Gumlet. If you have a modest number of images and want to pay almost nothing, Cloudflare's free tier is hard to argue with, and if you're on Craft Cloud you've already paid for it.

The srcset multiplier is the thing to keep an eye on under the per-transformation models. Five breakpoints across two formats is ten variants per image, and under Cloudflare's model that's ten unique transformations, every month, per image. format=auto saves you half of that, which is a good reason to let the service negotiate the format rather than specifying it yourself in the template. Under the bandwidth and per-origin-image models, breakpoints are free and you can be as granular as you like.

And a general warning about comparisons, including this one; the models move. Imgix has already replaced the origin-image pricing that every older comparison article describes, and Gumlet has reworked its tiers more than once. Check the pricing pages before you commit to anything.