How to Tell If a Website Uses Sanity

Sanity is a developer-first headless content management system known for its real-time, structured-content platform and its highly customisable editing environment (Sanity Studio). Like other headless systems it leaves no traditional CMS markup on the public site, so detecting it relies on the assets and APIs it serves: images from cdn.sanity.io and content from *.api.sanity.io. This guide explains those signals, how headless detection works in practice, the look-alike platforms to rule out, and what a Sanity build reveals about the team behind the site.

What is Sanity?

Sanity is a cloud-hosted headless CMS, launched in 2017, that has become a favourite of developer-led teams and agencies building modern websites and applications. Its distinguishing characteristics are a treatment of content as structured data (queried with its own GROQ query language or GraphQL), a real-time collaborative back end, and Sanity Studio — an open-source, fully customisable editing interface that teams configure in code. Content is stored centrally and delivered via API to any front end, putting Sanity firmly in the headless and composable category alongside Contentful, Prismic, Storyblok and Strapi.

For detection, the same principle applies as for any headless CMS: there is no CMS fingerprint in the rendered HTML — no generator tag, no admin path, no platform-specific markup on the public domain. The website can be built with any framework. What remains visible in the browser are Sanity's asset CDN and, on client-fetching sites, its content API. Sanity is especially popular with teams using modern JavaScript frameworks (it has first-class Next.js support), so its presence signals a contemporary, engineering-driven build.

How Sanity delivers content and assets

Sanity exposes two browser-visible systems, both on the sanity.io domain. The first is its image CDN: media is served from cdn.sanity.io/images/<projectId>/<dataset>/<assetId>-<dimensions>.<ext>, and files from cdn.sanity.io/files/<projectId>/<dataset>/.... These URLs embed the project ID (a short alphanumeric identifier) and the dataset (commonly production), and they frequently carry Sanity's image-pipeline transformation parameters (?w=, ?h=, ?fit=, ?auto=format). Because nearly every Sanity-powered site serves its images this way, a cdn.sanity.io URL is the single most reliable signal.

The second system is the content API. The live API is reached at <projectId>.api.sanity.io, and the cached, faster endpoint at <projectId>.apicdn.sanity.io; both encode the project ID in the subdomain. Whether you see these calls depends on rendering strategy: a client-side app fetches content directly from apicdn.sanity.io in the browser (visible in the Network tab), while a server-rendered or statically generated site queries the API on the server, leaving only the cdn.sanity.io asset URLs in the delivered HTML. Recognising this distinction tells you where to look.

How to tell if a website uses Sanity

Confirm at least one strong signal (the asset domain usually suffices).

1. Inspect image sources. In the Network tab or by right-clicking an image, check its URL. Media from cdn.sanity.io/images/<projectId>/<dataset>/ is the clearest signal, and the project ID is right there in the path.

2. Watch for API calls. Filter the Network tab for sanity. Calls to <projectId>.apicdn.sanity.io or <projectId>.api.sanity.io confirm a live, client-side Sanity integration and reveal the project ID in the subdomain.

3. View the page source. Search the HTML for cdn.sanity.io and sanity. Even server-rendered sites reference the image CDN in their markup.

4. Look for image-pipeline parameters. Sanity asset URLs commonly carry ?w=, ?auto=format and ?fit= parameters, characteristic of its image pipeline.

5. Read the project ID and dataset. The path or subdomain segments give you the project ID and dataset (e.g. production), uniquely identifying the Sanity project.

What the Sanity signals look like

GET https://cdn.sanity.io/images/ab12cd34/production/8f3a...-1600x900.jpg?w=1200&auto=format
GET https://ab12cd34.apicdn.sanity.io/v2023-05-03/data/query/production?query=*...   (client-side GROQ fetch)
HTML: <img src="https://cdn.sanity.io/images/ab12cd34/production/...-800x600.png?w=800&auto=format">

A cdn.sanity.io asset URL is conclusive on its own; an apicdn.sanity.io or api.sanity.io call confirms a client-side integration and reveals the project ID.

Sanity versus other headless CMSs — avoiding false positives

Match the asset and API domains exactly, since all headless systems hide behind APIs. Sanity uses cdn.sanity.io and *.api.sanity.io/*.apicdn.sanity.io; Contentful uses ctfassets.net and cdn.contentful.com; Prismic uses images.prismic.io and *.cdn.prismic.io; Storyblok uses a.storyblok.com; Strapi serves uploads from /uploads/. Each has a distinct CDN, so one image URL usually identifies the platform unambiguously. The main subtlety, as with all headless CMSs, is server-side rendering: when content is fetched at build time, you will not see apicdn.sanity.io calls in the browser, so check the image URLs rather than concluding "not Sanity" from the absence of API traffic. The project ID in the subdomain or path is the detail that turns "uses Sanity" into "uses this specific Sanity project".

How reliable is each Sanity signal?

Assets on cdn.sanity.io are definitive — the domain is specific to Sanity and the URL embeds the project ID and dataset. Calls to apicdn.sanity.io or api.sanity.io are equally conclusive and prove a client-side integration. The image-pipeline parameters are strong corroboration. The weakest situation is a site that proxies Sanity assets through its own domain, which is uncommon but possible on advanced builds; combined with build-time fetching, this can leave few browser signals. As a rule, a single cdn.sanity.io image URL settles it, and the project ID makes the finding precise.

What a Sanity build reveals about an organisation

Sanity is a developer-first platform, so finding it signals an engineering-led organisation or agency that values structured content, customisation and a modern, decoupled architecture. Teams choose Sanity specifically because they want to model content as data and to build a bespoke editing experience in code — a sign of technical sophistication and a real front-end engineering capability. The profile skews toward digital product teams, modern agencies, startups and brands with developer resources, often using Next.js. If you sell developer tools, edge or Jamstack hosting, front-end frameworks, search, or composable-DXP services, a Sanity site marks an aligned, technically capable buyer. Because Sanity's free and usage-based pricing scales from indie projects to enterprises, the surrounding stack (rather than the CMS alone) is the better guide to company size.

Sanity in a composable stack

Sanity is the content layer of a modern composable stack, and its presence should prompt you to map the rest. The front end is very often Next.js (Sanity invests heavily in Next.js integration), with Nuxt, Astro, Remix or SvelteKit also common, hosted on Vercel or Netlify. Composable builds frequently pair Sanity with a search provider, a commerce engine for headless e-commerce, an image or video service, and modern analytics. Because the architecture is API-first, you will often see several third-party APIs called from the browser. For an auditor, the valuable details are the project ID and dataset, whether content is fetched client-side or at build time, the front-end framework, and the hosting platform; together these reveal the maturity and shape of the company's composable architecture, with Sanity as its content backbone.

A quick Sanity confirmation walkthrough

Open the site with developer tools on the Network panel and reload. Look for image requests to cdn.sanity.io — any such request confirms Sanity, and the path reveals the project ID and dataset. Filter for sanity to see whether apicdn.sanity.io or api.sanity.io is called client-side, which indicates a client-fetching front end and shows the project ID in the subdomain. If you see only cdn.sanity.io images and no API calls, the site is almost certainly server-rendered or statically generated from Sanity at build time. The cdn.sanity.io asset URL alone is your conclusive signal.

A quick Sanity detection checklist

• Check image URLs for the cdn.sanity.io/images/<projectId>/<dataset>/ pattern — conclusive on its own.
• Filter the Network tab for sanity to spot apicdn.sanity.io / api.sanity.io calls.
• Read the project ID and dataset from the image path or API subdomain.
• Note image-pipeline parameters (?auto=format, ?w=) as corroboration.
• Identify the front-end framework (often Next.js) and host to map the stack.
• Don't rule out Sanity just because no API call is visible — build-time fetching hides it.

Detecting Sanity at scale

Checking one site is quick, but mapping headless-CMS adoption across many domains — to find developer-led, composable companies — calls for automation. StackOptic detects Sanity via its asset and API domains, alongside thousands of other technologies, from a real browser, catching both client-side and server-rendered integrations. Because Sanity so often travels with Next.js and edge hosting, a scan that captures the whole stack — not Sanity in isolation — lets you build a precise list of modern, developer-led teams, which is far more valuable for outreach than the CMS name alone. For related reading, see our guide to telling what CMS a website is using and the full Sanity technology profile.