Resize, optimize, and serve images at the edge

After this lesson you'll be able to upload an image to Cloudflare Images, request resized/format-converted variants via URL, and explain the pricing and configuration split between hosted storage and transform-only usage.

Cloudflare Images is a managed pipeline for the three things almost every app needs to do with pictures: get them stored somewhere, produce the right size/format for each surface (thumbnail, hero banner, retina, mobile), and serve them fast worldwide. It bundles three capabilities that used to require separate infrastructure: a storage layer for uploaded originals, an on-the-fly transformation engine (resize, crop, format conversion to WebP/AVIF, quality tuning), and delivery through Cloudflare's global CDN so transformed variants are cached at the edge close to the requester. You upload one original; every consumer gets a version sized and encoded for them, generated on first request and cached after that.

How it works

Two URL shapes cover the two source modes:

• Your own origin (zone-based transforms): https://<your-zone>/cdn-cgi/image/<OPTIONS>/<path-to-source-image> — Cloudflare fetches the original from wherever it already lives (your web server, R2, S3) and returns a transformed version. Nothing is stored by Cloudflare; every unique combination of source image + options is a billable transformation.
• Cloudflare-hosted images: https://imagedelivery.net/<ACCOUNT_HASH>/<IMAGE_ID>/<VARIANT-OR-OPTIONS> — the original was uploaded to and is stored by Cloudflare Images; you request either a named variant (a preset you configured, e.g. thumbnail) or, if flexible variants are enabled on your account, free-form options directly in the URL.

In both cases, <OPTIONS> is a comma-separated list — width/w, height/h, fit (cover, contain, crop, scale-down, etc.), quality/q, and format/f. format=auto is the one worth defaulting to almost everywhere: Cloudflare inspects the requesting browser's Accept header and serves AVIF or WebP where supported, falling back to JPEG/PNG otherwise — one URL, best format per client, and it still counts as a single billable transformation no matter how many different encoded outputs it produces.

The first request for a given image + option combination does the actual resize/encode work and the result is cached at Cloudflare's edge; subsequent requests for that same combination are served from cache without repeating the transform. That's why pricing is based on unique transformations per month, not total requests.

Worked example

Upload an image to Cloudflare's hosted storage via the API:

curl -X POST \
  "https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/images/v1" \
  -H "Authorization: Bearer <API_TOKEN>" \
  -F "file=@./product-photo.jpg" \
  -F "metadata={\"sku\":\"SKU-1284\"}"

A successful response includes the image's ID and its delivery URL variants:

{
  "result": {
    "id": "3e4a1a9b-...-9c2f",
    "filename": "product-photo.jpg",
    "uploaded": "2026-07-03T10:15:00Z",
    "variants": [
      "https://imagedelivery.net/<ACCOUNT_HASH>/3e4a1a9b-...-9c2f/public"
    ]
  },
  "success": true,
  "errors": [],
  "messages": []
}

Request a resized, format-converted variant on the fly by putting options straight in the URL (requires flexible variants enabled on the account — otherwise you request one of your predefined named variants instead, e.g. /thumbnail):

<!-- 400px wide, best format for the browser, quality 85 -->
<img
  src="https://imagedelivery.net/<ACCOUNT_HASH>/3e4a1a9b-...-9c2f/w=400,format=auto,quality=85"
  alt="Product photo"
>

<!-- square crop for a grid thumbnail -->
<img
  src="https://imagedelivery.net/<ACCOUNT_HASH>/3e4a1a9b-...-9c2f/w=200,h=200,fit=cover,format=auto"
  alt="Product thumbnail"
>

Same idea against an image that stays in your own storage (e.g. R2 or an existing web origin), using your zone instead of imagedelivery.net:

https://shop.example.com/cdn-cgi/image/width=800,format=auto,fit=scale-down/images/product-photo.jpg

Pricing

As of this writing, Cloudflare prices the two source modes separately:

A "unique transformation" is one billable unit per source image + option combination per month — requesting the same width/format/quality repeatedly (cache hits) doesn't multiply the charge, and format=auto serving AVIF to one client and WebP to another still counts once. Transforming images that stay in your own origin storage only incurs the transformation charge — there's no separate storage or delivery line item, because Cloudflare isn't storing the bytes. Pricing changes; confirm current numbers on the live pricing page linked below before quoting them.

Use cases

• User-generated content platforms — users upload photos of wildly inconsistent size and format; hosted storage plus flexible variants means you don't pre-generate every size you might ever need, and moderation/metadata can travel with the stored image record.
• E-commerce product images — one high-res original serves thumbnail grids, PDP hero images, and zoom views, each as a different variant, without maintaining separate resized copies in your own storage.
• Responsive image delivery for existing sites — if images already live on your origin or in R2/S3, zone-based transforms (/cdn-cgi/image/...) let you add resizing and modern-format delivery via srcset without migrating storage at all.
• Avatar/profile-picture pipelines — a single uploaded avatar rendered at every size an app's UI needs (nav icon, profile page, notification thumbnail) from one stored original.