If you have followed a Cloudflare tutorial written before 2026, installed a plugin with “resizing” in its name, or inherited a Worker that rewrites image URLs, you have probably hit something confusing. The Cloudflare dashboard no longer has a feature called Image Resizing. The documentation does not mention it either. Nothing in your setup has broken, but the name you were searching for has quietly gone.

The feature is now called Image Transformations. It does the same job, through the same URL structure, with the same parameters. What changed is the name, where it sits in the dashboard, and how it is billed. That last part is worth reading carefully, because the billing model is genuinely different from what most older guides describe.

The short version: your existing URLs and Workers keep working. Cloudflare renamed Image Resizing to Image Transformations and folded it into the Cloudflare Images product. The Free plan now includes five thousand unique transformations a month, which is new, and beyond that you pay per thousand rather than needing a Pro subscription.

What Actually Changed

The rename is the visible part, but three things moved at once, and conflating them is where most of the confusion comes from.

The name. Image Resizing became Image Transformations. Cloudflare’s own documentation now uses the new term throughout with no reference to the old one, which is why searching for the old name increasingly turns up third-party pages rather than official docs.

The product boundary. Transformations used to feel like a standalone feature you switched on. It now sits inside Cloudflare Images, the broader product covering storage and delivery. This causes a specific misunderstanding worth clearing up straight away: you do not have to store your images in Cloudflare Images to transform them. You can transform images that live on your own origin, in R2, or anywhere else publicly reachable. Storage and transformation are separate concerns that happen to share a product page.

The billing. This is the substantive change. Older guides tell you image resizing requires a Pro plan or higher. That is no longer how it works.

What It Costs Now

On the Free plan you get five thousand unique transformations each month at no cost. Beyond that, on a paid Images plan, the rate is fifty cents per thousand unique transformations per month.

The word doing the heavy lifting there is unique. A transformation is counted once per distinct combination of source image and parameters, per calendar month. Resizing one photograph to one hundred pixels wide and then to two hundred pixels wide is two transformations. But serving that same one-hundred-pixel version to fifty thousand visitors during the month is still one transformation, because the repeats cost nothing.

That distinction matters more than the headline price. Your bill scales with how many distinct image variants your site produces, not with how much traffic you get. A busy site with a small, stable set of images can sit comfortably inside the free allowance. A site with a large catalogue and many breakpoints will burn through it regardless of how few visitors it has.

There is one useful subtlety in how format conversion is counted. If you use the automatic format parameter, and Cloudflare serves AVIF to some browsers and WebP to others, that counts as a single transformation rather than two. Automatic format selection is effectively free from a billing perspective, which is a good reason to use it rather than requesting formats explicitly.

What You Need To Update

For most setups, nothing functional. The URL format is unchanged, the parameters are unchanged, and Workers that build transformation URLs keep working exactly as before. This was a rename, not a migration.

What is worth updating is everything that refers to the old name, because those references now send people looking for documentation that no longer exists.

Internal documentation and runbooks are the obvious one. If your deployment notes say to enable Image Resizing in the dashboard, whoever follows those notes next will not find that setting.

Plugin and tool names are the awkward one, mine included. The WordPress plugin I maintain is still called Cloudflare Image Resizing, because renaming a published plugin breaks existing installations and search continuity. It works with Image Transformations exactly as it always did. If you are searching the WordPress plugin directory for something to handle this, expect to find the old terminology for a while yet.

Monitoring and cost alerts deserve a second look. If you set up billing alerts around the old plan-tier model, they are watching for something that no longer applies. The thing to watch now is unique transformation count against the five thousand monthly allowance.

Where People Get Caught Out

Two mistakes come up repeatedly, and both cost money rather than breaking anything.

Generating more variants than you need. Because billing follows distinct variants, a responsive image setup with eight breakpoints multiplies your transformation count by eight. Most sites do not need eight. Three or four well-chosen widths cover the realistic range of devices, and each one you remove is a proportional saving. Our guide to responsive images covers how to pick breakpoints that earn their place.

Cache-busting query strings. If your build process appends a changing version parameter to image URLs, every deploy creates a fresh set of unique transformations. This is the single most common way a site quietly runs up a transformation bill: the images have not changed, but their URLs have, so Cloudflare treats each one as new.

Checking It Is Actually Working

The rename makes this worth verifying rather than assuming, because a misconfigured setup fails silently. Your images still load, they are simply served untransformed at full size, and the only symptom is a slow page.

The quickest check is the response headers on an image request. A transformed response carries a cf-resized header describing what was done, and the content-type reflects the format that was actually served. If you asked for automatic format selection and a modern browser is still receiving the original JPEG, the transformation is not being applied.

The second check is the size on the wire. Open the network panel, reload, and compare the transferred size of an image against the original file on your origin. A photograph that arrives at the same byte count it has on disk has not been touched. This catches the common case where the URL pattern is subtly wrong and the request is passing straight through.

Worth knowing: transformations only apply to images served through the zone where the feature is enabled. If your images are on a subdomain that is not proxied through Cloudflare, or you are pulling from a third-party host that is not on your account, requests bypass the whole mechanism. This trips people up after a migration, when image URLs were repointed and nobody rechecked which hostname was actually serving them.

Whether You Should Use It At All

Transformations suit sites where images vary in size or arrive from user uploads, and where storing every pre-rendered variant is impractical. A product catalogue where the same photograph appears as a thumbnail, a grid tile and a full-size view is the natural case. So is any site where editors upload whatever their camera produced and you need it usable without manual intervention.

They suit you less well if you have a small, fixed set of images that rarely change. In that case, generating your sizes once at build time and serving them as static files costs nothing at all, and no transformation service beats free.

For a fuller treatment of how the URL format and the Worker approach differ, see our guide to Cloudflare Image Transformations . If you are weighing up where the images themselves should live, Cloudflare R2 for image hosting covers the storage side and its zero egress fees.

Getting It Set Up Properly

Most of the value in image delivery comes from decisions made once and then left alone: which widths you actually serve, whether format selection is automatic, and whether your URLs are stable enough to benefit from the repeat-request discount. Those are quick to get right at the start and tedious to unpick later.

Mecanik builds and audits image delivery as part of website development work, and the WordPress plugin that automates this on WordPress is free to use. If your site is slow and you suspect images are the reason, a WordPress performance audit will tell you whether that hunch is right before you spend anything.

Related reading: Cloudflare Image Transformations - Resize and Optimize on the Fly , Cloudflare Image Resizing for WordPress , Cloudflare Image Transformations vs WordPress Image Plugins and Cloudflare Image Resizing for PrestaShop .

Frequently Asked Questions

Is Cloudflare Image Resizing discontinued? No. It was renamed to Image Transformations and folded into the Cloudflare Images product. The URL format, parameters and Worker integrations are unchanged, so existing setups keep working without modification.

Do I still need a Pro plan for image resizing? No. That requirement belonged to the older model. The Free plan now includes five thousand unique transformations per month, and beyond that you pay fifty cents per thousand on a paid Images plan.

What counts as a unique transformation? One distinct combination of source image and parameters, counted once per calendar month. Serving the same transformed image to many visitors counts once. Requesting the same image at two different widths counts twice.

Do I have to store images in Cloudflare Images to transform them? No. You can transform images hosted on your own origin, in R2, or anywhere else publicly reachable. Storage and transformation are separate, even though they now share a product page.

Why is the WordPress plugin still called Image Resizing? Renaming a published plugin breaks existing installations and search continuity, so the name stays. It works with Image Transformations exactly as before, because only Cloudflare’s terminology changed.