Introduction
Once you've decided to use Cloudinary (a cloud service specializing in image transformation and delivery), the next question is how to get product images that live in Shopify delivered to users via Cloudinary.
This article lays out the full picture in three steps, based on the setup actually built for the EC site I operate. It stays out of program code. If you understand what to decide and which mechanism to choose at each step, you can use this directly as a blueprint — whether you're briefing a developer or instructing an AI agent (AI-powered development support).
The Build at a Glance — Three Steps
There are three jobs: "sync" to move Shopify images into Cloudinary, "URL rules" to define which image gets called with which transformation, and "display" to wire it into your pages.
Product created or updated
Extracts images from product data
Converts and stores, ready to serve
The diagram above shows the flow where registering a product automatically carries its images into Cloudinary.
Requests an image
Returns the converted image
Your server is not involved
This is the delivery side — in one sentence, Cloudinary hands images to users directly, and your own server never enters the path.
Step 1: Sync Images into Cloudinary
Option A: Automatic Sync via Webhook
The first option uploads images to Cloudinary automatically the moment a product is created or updated in Shopify. Shopify provides Webhooks (a mechanism that sends a notification when something happens) for events like "product created" and "product updated." Receive that notification, pull the images out of the product data, and hand them to Cloudinary — the whole chain runs unattended.
Once built, product staff simply register products in Shopify as they always have. Images make their own way to Cloudinary in the background. Zero ongoing operational effort is this option's biggest strength.
Option B: Fetch on Demand
The second option skips advance syncing: the first time an image is requested, Cloudinary fetches it from Shopify. Cloudinary supports a request style (fetch) that amounts to "go get the image at this URL, convert it, and remember it," so you can start using it with almost nothing to build.
The trade-off is that the very first request is slow, since Cloudinary has to retrieve the image from Shopify, and if Shopify's image URL changes, it must be re-fetched. You trade a little speed and certainty for a lot of convenience.
Choosing Between Them
In one sentence: Webhook sync for serious production use, fetch to try things out. For the site I operate, we started with fetch to confirm the benefits, then switched to Webhook sync. Taking it in stages means you invest in the build only after seeing the results.
Step 2: Decide the Image URL Rules
Keep URL Assembly in One Place
Cloudinary images are called with URLs that specify which image and which transformations. If each page assembles these URLs its own way, changing your transformation policy later means fixing every page — so instead, create a single converter that takes a product ID and image ID and returns the Cloudinary URL.
When briefing the implementation, saying "please centralize image URL assembly in one shared function" gets the intent across. A structure where changes happen in exactly one place is the whole point of this step.
Leave Size and Quality on Automatic
For the transformation instructions in each URL, we settled on a width plus two automatics: f_auto (automatic format selection) and q_auto (automatic quality optimization). Format switching per browser and the quality-versus-size balance are both left to Cloudinary. The fewer things a human has to judge, the easier operations get — when in doubt, lean on automatic.
Step 3: Display in Next.js
Swap In a New "Connector" for Images
Next.js (a framework that serves as the foundation for building websites) has a built-in image feature that normally converts images on Vercel's side. To point that conversion at Cloudinary instead, you configure what's called a custom loader — a connector with one simple job: when a page requests an image, assemble the Cloudinary URL using the rules from Step 2 and hand it over. Pages barely change; only the source of the images switches to Cloudinary.
Alongside this, register Cloudinary's domain (its delivery address) in Next.js's allow list — a formality required for loading images from an external source.
A Blurred Placeholder Improves Perceived Speed
Cloudinary can auto-generate a tiny blurred version of each image, around 20px wide. Use it as the stand-in (placeholder) while the real image loads, and instead of a blank white box, users see a faint preview that sharpens into the full image. On top of raw speed, it's a small touch that reduces the feeling of waiting.
Add a Safety Net for Display Failures
In case Cloudinary ever fails to return an image, add a fallback that switches to the original Shopify image. It will rarely trigger, but it rules out the worst case — a product page with no images at all — so it costs little and is worth having.
Summary
The Shopify → Cloudinary delivery flow comes together in three steps: choose a sync method, centralize the URL rules in one place, and swap in the display connector. Once assembled, nothing changes for product staff — while the image load and costs simply disappear from your server.
Start small with fetch, confirm the benefits, then move to Webhook sync. That order keeps the migration low-risk.