How to Tell If a Website Uses Cloudinary

Cloudinary is one of the most widely used media-management and image/video CDN platforms, handling the storage, transformation, optimisation and delivery of media for a huge range of websites and apps. Because media is delivered straight from Cloudinary's own URLs, detecting it is refreshingly direct: open the Network tab and look for assets served from res.cloudinary.com. This guide walks through every reliable signal, the transformation-URL architecture that produces them, the look-alikes to rule out, and what a Cloudinary integration tells you about the site and the team behind it.

What is Cloudinary?

Cloudinary, founded in 2012, is a cloud platform built specifically for managing and delivering visual media at scale. Rather than storing images and video on the origin server and serving them as-is, a site uploads media to Cloudinary, which then delivers optimised, transformed versions on demand through its global CDN. The transformations are driven entirely by the URL: a single source image can be resized, cropped, reformatted, compressed, watermarked or otherwise manipulated simply by changing parameters in the delivery URL, with the result cached at the edge. This makes it a favourite of teams that care about image performance, responsive imagery and developer ergonomics.

For detection, the key context is that Cloudinary is a deliberate, developer-implemented choice aimed at media-heavy or performance-conscious sites — ecommerce catalogues, publishers, marketplaces, SaaS apps with rich media, and modern frameworks. Its presence signals a team that has invested in automated media optimisation rather than uploading static images by hand. Because the media is served from Cloudinary-controlled URLs (or a CNAME pointing at Cloudinary), the integration is highly visible in the browser and hard to disguise, which makes it one of the easier CDN-class technologies to confirm.

How Cloudinary delivers media

Cloudinary's delivery URLs follow a consistent, recognisable structure: https://res.cloudinary.com/<cloud_name>/image/upload/<transformations>/<public_id>.<format> (with video/upload/ for video and raw/upload/ for other files). The cloud name — the first path segment after the domain — uniquely identifies the Cloudinary account and is entirely public, since it is how the delivery endpoint knows whose media to serve. The transformations segment is the heart of Cloudinary: comma-separated codes such as w_800 (width), h_600 (height), c_fill (crop mode), f_auto (automatic best format), q_auto (automatic quality), dpr_auto (device pixel ratio) and many more, chained together to produce exactly the variant the page needs.

Because everything is encoded in the URL, you can read a great deal from a single Cloudinary asset request: the account (cloud name), the optimisation strategy (whether f_auto/q_auto are used), and how responsive the implementation is (multiple widths and dpr variants). Some sites front Cloudinary with a custom CNAME or use the <cloud_name>-res.cloudinary.com private-distribution pattern, in which case the host changes but the /image/upload/ path structure and transformation parameters remain — so those path patterns are your most portable signal. Understanding this URL-driven model makes every detection step below obvious.

How to tell if a website uses Cloudinary

Confirm at least one strong signal (a single asset URL usually suffices).

1. Inspect image sources. Right-click an image and copy its URL, or open the Network tab and look at where media loads from. A res.cloudinary.com/<cloud_name>/image/upload/... URL is the definitive signal.

2. Look for transformation parameters. Even on a custom host, a path containing /image/upload/ followed by comma-separated codes like f_auto,q_auto,w_1200 is highly characteristic of Cloudinary.

3. Read the cloud name. The path segment after the domain (or after the custom host's /image/upload/) is the cloud name, which identifies the account.

4. Check the Network tab for the host. Filter for cloudinary. Assets from res.cloudinary.com or *-res.cloudinary.com confirm the platform; a custom CNAME may need the path pattern to confirm.

5. View the page source. Search the HTML for cloudinary or res.cloudinary.com; image src and srcset attributes frequently reference it directly.

What the Cloudinary signals look like

<img src="https://res.cloudinary.com/acme-store/image/upload/f_auto,q_auto,w_1200,c_fill/products/widget.jpg">
<img srcset="https://res.cloudinary.com/acme-store/image/upload/w_400/.../hero.jpg 400w,
             https://res.cloudinary.com/acme-store/image/upload/w_800/.../hero.jpg 800w">
// Custom distribution: https://media.acme.com/image/upload/f_auto,q_auto/...

A res.cloudinary.com asset URL is conclusive on its own; the /image/upload/ path with transformation codes confirms Cloudinary even behind a custom host.

Cloudinary versus other media CDNs — avoiding false positives

Match the host and URL pattern to keep image services distinct. Cloudinary uses res.cloudinary.com and the /image/upload/<transformations>/ pattern; imgix uses <source>.imgix.net with query-string parameters (?w=&auto=format); Contentful serves media from ctfassets.net; Sanity from cdn.sanity.io; Shopify from cdn.shopify.com. The key structural difference is that Cloudinary encodes transformations in the path (comma-separated codes), whereas imgix encodes them in the query string — so the location of the parameters distinguishes the two even at a glance. The main subtlety is custom CNAMEs and private distributions, which hide the res.cloudinary.com host; in those cases the /image/upload/ path and the comma-separated transformation codes are the reliable signals. Do not confuse Cloudinary the media platform with a general-purpose CDN like Cloudflare or Fastly, which deliver assets but do not impose this transformation-URL structure.

How reliable is each Cloudinary signal?

A res.cloudinary.com asset URL is definitive and reveals the cloud name. The /image/upload/ path with comma-separated transformation codes is equally strong and survives custom hosting. The cloud name reliably identifies the account. The weakest situation is a site that proxies Cloudinary entirely through a brand domain and strips obvious markers — uncommon, but there you rely on the path structure and the transformation syntax. Because media loads on essentially every page, you rarely need to hunt for the signal; a single image inspection usually settles it. As a rule, the host or the /image/upload/ transformation pattern confirms Cloudinary immediately.

What a Cloudinary integration reveals about a site

Finding Cloudinary signals a media-conscious site with a development team that invested in automated image and video handling. It is common on ecommerce stores with large product catalogues, publishers and media sites, marketplaces, and modern web apps where responsive, optimised imagery matters for both performance and user experience. The transformation parameters in evidence refine the read: heavy use of f_auto/q_auto and multiple responsive widths indicates a performance-focused, modern implementation, while basic resizing suggests a lighter touch. If you sell performance, media, ecommerce or developer tooling, a Cloudinary site marks a team that already values media optimisation and has budget for specialised infrastructure. The cloud name can also help you recognise when several sites or brands share one Cloudinary account, indicating a consolidated media operation.

What finding Cloudinary means for sales, agencies and competitive research

For sales and prospecting, Cloudinary marks a media-heavy, technically capable site — a fit for performance tools, ecommerce media services, DAM (digital asset management) products, and developer infrastructure. The sophistication of the transformation usage hints at how mature the team's media practice is and where there is room to help.

For agencies and consultants, finding Cloudinary tells you the client takes media performance seriously, so engagements can focus on Core Web Vitals, responsive imagery, video optimisation or media-workflow improvements rather than basic image hygiene. It signals a client comfortable with paid infrastructure.

For competitive and market research, Cloudinary adoption indicates how seriously a sector treats visual media and performance. Spotting a competitor on Cloudinary tells you they optimise and transform media automatically, useful context when benchmarking page speed and visual quality.

Cloudinary in the wider stack

Cloudinary usually sits within a performance- and media-focused stack. On ecommerce it accompanies a store platform and often a broader CDN (Cloudflare, Fastly) handling the rest of the site while Cloudinary specialises in media. On modern web apps it pairs with frameworks like Next.js (which has native Cloudinary loaders), edge hosting, and analytics. Publishers may combine it with a CMS and a video platform. For an auditor, the valuable details are the cloud name, whether automatic optimisation (f_auto/q_auto) and responsive variants are in use, whether a custom distribution domain is configured, and the surrounding CDN and framework; together these reveal not just that the site uses Cloudinary but how mature and performance-focused its media strategy is.

A quick Cloudinary confirmation walkthrough

Open the site with developer tools on the Network panel and reload, then sort or filter the requests by domain. Look for assets on res.cloudinary.com (or *-res.cloudinary.com); click one and read the path to capture the cloud name and the transformation codes. If images load from a brand domain instead, look for the /image/upload/ segment and comma-separated parameters in the path, which confirm Cloudinary behind a CNAME. View the source and search image src/srcset attributes for cloudinary. A single res.cloudinary.com asset URL — or the /image/upload/ transformation pattern — is enough to confirm Cloudinary and identify the account.

A quick Cloudinary detection checklist

• Inspect image URLs for the res.cloudinary.com/<cloud_name>/image/upload/ pattern — conclusive.
• Look for comma-separated transformation codes (f_auto, q_auto, w_, c_fill) in the path.
• Read the cloud name from the path to identify the account.
• Check for a custom CNAME or <cloud_name>-res.cloudinary.com distribution.
• Distinguish Cloudinary (path-based params) from imgix (query-string params).
• Note the surrounding CDN and framework to map the media stack.

Detecting Cloudinary at scale

Checking one site is quick, but mapping media-CDN adoption across many domains — to find media-heavy, performance-focused businesses — calls for automation. StackOptic detects Cloudinary and thousands of other technologies from a real browser, including custom-distribution setups, so you can build a list of media-conscious sites and infer their wider performance stack. For related reading, see our guide to telling if a website uses Cloudflare or another CDN and the full Cloudinary technology profile.