Sanity

What Is Sanity?

Sanity is a headless content management system built around a structured, real-time content store that the company calls the Content Lake. Rather than treating content as pages of formatted text, Sanity treats it as structured data, every document is JSON with a defined schema, which can be queried, transformed, and delivered to any website, app, or device. This data-first philosophy is what positions Sanity as a "composable content platform" rather than a traditional website tool.

Sanity is widely used by product and engineering teams that want maximum control over both their content model and their editing experience. The editing environment, Sanity Studio, is an open-source, React-based application that developers configure and customize in their own codebase, so the interface editors use can be shaped precisely to a project's needs rather than accepted as a fixed dashboard. Combined with the hosted Content Lake that stores and serves the content, Sanity gives teams an unusual degree of flexibility on both the editorial and the delivery side.

Sanity is a hosted, API-first platform rather than a browser extension or a plugin for another CMS. The structured content lives in Sanity's Content Lake and is delivered through its APIs and asset CDN, while the public website is whatever the development team builds and hosts separately. Because a headless CMS is a back-end service, the website itself can be built in any framework and hosted anywhere, so detection leans heavily on the asset and API domains Sanity uses rather than on any generator tag in the rendered page.

It helps to frame who Sanity is for. The platform targets developers and the product teams they work with, especially those who want to define their own content schemas in code and tailor the editing experience, rather than non-technical users seeking an all-in-one builder. The people who benefit most are engineers who value a queryable, structured content store and a customizable studio, paired with editors who want a polished, project-specific editing interface and real-time collaboration. That positioning explains Sanity's code-defined schemas, its GROQ query language, and its emphasis on developer control.

How Sanity Works

At the foundation of Sanity is the Content Lake, a hosted, real-time document store. Every piece of content is a JSON document conforming to a schema the developer defines, and documents can reference one another to model relationships. Because content is stored as structured data rather than rendered HTML, the same content can be delivered to a website, a mobile app, a digital display, or any other channel without being locked to a single presentation.

Content is queried with GROQ (Graph-Relational Object Queries), Sanity's purpose-built query language for JSON documents. GROQ lets developers filter, project, and join across documents concisely, often more so than GraphQL for content-shaped queries, and Sanity also exposes a GraphQL API for teams that prefer it. Queries can run at build time for static sites or at request time for dynamic ones, and the Content Lake's real-time nature means listeners can receive updates as content changes.

The editing experience is Sanity Studio, an open-source single-page application built with React that developers run and customize. Schemas, custom input components, validation rules, and editorial workflows are all configured in code, so the studio can be tailored to a specific project. Studio supports real-time collaboration, multiple editors can work on the same document simultaneously with live presence, and full content history, so any previous revision can be inspected and restored.

When a page is built or requested, the front end issues a GROQ (or GraphQL) query to Sanity's API, receives structured JSON, and renders it however the developer chooses. Images and other media are requested from Sanity's asset CDN, which can resize, crop, and convert formats on the fly through URL parameters. None of this dictates where the site is hosted; Sanity supplies the content and assets, and the front-end framework handles presentation and delivery.

A useful way to picture the workflow is to follow a content type from definition to display. A developer defines a schema, say, a "case study" with a title, a hero image, a body of structured rich text, and references to related products, and configures Sanity Studio to present those fields with appropriate inputs and validation. Editors open the customized Studio, create case studies, collaborate in real time, and publish. The front end, perhaps a Next.js or Nuxt app, runs a GROQ query for the latest case studies, receives clean JSON, and renders each one with its own components, pulling images from Sanity's CDN with the exact dimensions it needs. The editor enjoyed a tailored editing experience, and the developer retained full control over both the data model and the rendered output.

This separation, structured content in the Content Lake, customizable editing in Studio, and presentation in the framework of choice, is central to why engineering-led teams adopt Sanity. It treats content as a reusable asset rather than as pages bound to one website.

How to Tell if a Website Uses Sanity

Because Sanity is a headless back end, the website's front end can be built in any framework and reveals little about the CMS by itself. Detection therefore leans on the asset and API domains Sanity uses, which StackOptic inspects from the server side and which you can confirm by hand.

Sanity asset CDN. The strongest and most visible signal is media served from cdn.sanity.io. Sanity's image and file assets are delivered from this domain, typically with project-specific path segments and image-transformation parameters. Because nearly every Sanity-backed site renders images through this CDN, image URLs on cdn.sanity.io are a dependable tell even though the page itself is hosted elsewhere.

Sanity API endpoints. Content is queried from Sanity's API at api.sanity.io and apicdn.sanity.io (the CDN-backed API used for cached reads). If you can observe the front end fetching from one of these endpoints in the Network tab, that is strong confirmation. On statically generated sites these queries happen at build time and may not appear in the browser, which is why the asset CDN is often the more visible signal.

Image URL parameters. Sanity's image pipeline uses URL parameters to control width, height, crop, and format. Seeing those transformation parameters on cdn.sanity.io image URLs reinforces detection and helps distinguish Sanity from other CDNs.

Front-end framework pairing. Sanity is commonly paired with React-based frameworks such as Next.js, as well as Nuxt and others. Detecting a modern framework alongside cdn.sanity.io or api.sanity.io is a strong combined signal. The framework alone proves nothing, headless CMS detection is about correlating the front-end stack with the back-end asset and API domains.

Here is how to check each signal yourself:

Method	What to do	What Sanity reveals
Browser DevTools	Open the Network tab and reload	Image requests to cdn.sanity.io, query calls to api.sanity.io / apicdn.sanity.io
View Source	"View Page Source" and search for sanity.io	cdn.sanity.io asset URLs embedded in the rendered HTML
curl -s	Run curl -s https://example.com and grep the HTML	Image and asset URLs pointing at cdn.sanity.io
Wappalyzer	Run the extension on the live page	Often identifies "Sanity" under CMS
BuiltWith	Look up the domain	Current and historical Sanity detection

A quick command-line check is curl -s https://example.com | grep -i "sanity.io". A match strongly suggests Sanity. If you are unsure whether the site is headless at all, our guides on how to find out what technology a website uses, how to check if a website uses React, Vue, or Angular, and how to check what JavaScript libraries a website uses help establish the front-end and back-end picture together.

It is worth being candid about the limits of headless detection. On a statically generated Sanity site, content is queried at build time and baked into the HTML, so a visitor's browser may never make a live call to api.sanity.io. In that case the most reliable evidence is the image URLs, which usually still point at cdn.sanity.io because images are requested on demand for optimization. When even the images are proxied through the site's own domain or a generic CDN, external detection becomes genuinely hard, and an honest tool reports uncertainty rather than guessing. Server-side analysis helps by fetching the raw, fully rendered HTML and scanning it for sanity.io references that a casual glance in the browser might miss, but no technique can reliably detect a headless back end that has been fully hidden behind a custom asset domain.

Key Features

• Structured Content Lake. A hosted, real-time document store where all content is JSON with a developer-defined schema.
• GROQ query language. A concise, purpose-built query language for JSON content, with a GraphQL API also available.
• Customizable Sanity Studio. An open-source, React-based editing environment configured entirely in code.
• Real-time collaboration. Multiple editors work on the same document simultaneously with live presence.
• Full content history. Complete revision history with the ability to inspect and restore previous versions.
• Asset CDN with on-the-fly imaging. Media served and transformed through cdn.sanity.io via URL parameters.
• Omnichannel delivery. The same structured content powers websites, apps, and other channels.

Pros and Cons

Pros

• Treats content as structured, reusable data that can feed many channels, not just one website.
• Highly customizable editing experience through code-configured Sanity Studio.
• Powerful, concise querying with GROQ, plus a GraphQL option.
• Real-time collaboration and complete content history support team editorial workflows.

Cons

• Requires development effort to define schemas and configure the studio; not an all-in-one builder.
• GROQ is a new language for teams to learn, even if it is concise once mastered.
• Front-end hosting and build pipeline remain the team's responsibility.
• Reasoning about the live site externally takes more effort than a traditional themed CMS.

Sanity vs Alternatives

Sanity competes with other headless and composable content platforms. The table below clarifies where it fits.

Platform	Modeling approach	Query/delivery	Best for
Sanity	Code-defined schemas, customizable Studio	GROQ + GraphQL, asset CDN	Engineering teams wanting structured content and a tailored editor
Prismic	Code-defined slices via Slice Machine	REST content API + asset CDN	Framework teams wanting component-aligned content
Contentful	Editor-defined content types	REST/GraphQL APIs	Omnichannel content at scale
Strapi	Visual or code content types, self-hosted	Auto-generated REST/GraphQL	Teams wanting open-source, self-hosted control
WordPress	Themes and plugins (or headless via REST)	PHP rendering or REST API	General-purpose content sites

If a site turns out not to be Sanity, the same asset-domain techniques identify the real headless back end; compare Sanity with Prismic to see two different approaches to code-first, developer-focused content management.

Use Cases

Sanity is the natural choice for product and engineering teams that want to model content as structured data and feed it to one or more front ends. Teams use it to power marketing sites, product catalogs, documentation, and in-app content from a single structured source, with a custom editing experience tailored to each project.

It also fits companies running omnichannel content across web and mobile, agencies that want to deliver a bespoke editing interface to clients, and content-heavy products that need real-time collaboration and a full revision history. For technology and competitive research, detecting Sanity alongside a modern framework signals an engineering-led organization with a structured, composable content strategy.

Picture a few typical adopters. A software company might store all of its marketing copy, blog posts, and in-product help content in Sanity's Content Lake, querying it with GROQ from a Next.js site and a mobile app so both stay in sync. An agency might configure a custom Sanity Studio for a client, complete with branded inputs and validation, then hand over editing while retaining control of the schema. A documentation or media team might rely on real-time collaboration and content history to coordinate many authors safely. The common thread is a team that treats content as structured, reusable data rather than as pages tied to a single site.

From a sales-intelligence standpoint, spotting Sanity on a domain is a meaningful signal. It typically indicates a developer-led organization comfortable with headless, composable architectures, which is valuable context for vendors selling developer tools, hosting, or front-end services. Because headless detection requires correlating asset domains with the front-end stack, surfacing it automatically across many domains, rather than inspecting each site by hand, is exactly where automated technology detection earns its keep.

Frequently Asked Questions

Is Sanity a headless CMS?

Yes. Sanity is an API-first, headless content management system. It stores content as structured JSON in its hosted Content Lake and delivers it over APIs (queried with GROQ or GraphQL), leaving the presentation entirely to the developer's chosen front end. Unlike a traditional CMS that renders themed pages, Sanity supplies structured data that a separate application, often built in React or Next.js, fetches and renders. That decoupling is what makes it headless.

How do I detect Sanity if the site is statically generated?

On a statically generated site, content is queried from Sanity at build time and baked into the HTML, so the browser may never call the Sanity API live. The most reliable signal is then the image URLs, which usually still point at cdn.sanity.io because images are requested on demand for optimization, often with transformation parameters. Search the page source or Network tab for sanity.io. If even the images are proxied through a custom domain, external detection becomes difficult and is best reported as uncertain.

What is GROQ?

GROQ stands for Graph-Relational Object Queries, Sanity's query language designed specifically for its JSON document store. It lets developers filter documents, project exactly the fields they need, and join across references in a single concise query, often more compactly than GraphQL for content-shaped data. Sanity also exposes a GraphQL API, so teams can use whichever query approach they prefer when fetching content for their front end.

What is the Content Lake?

The Content Lake is Sanity's hosted, real-time backend that stores, indexes, and serves all content as structured JSON documents. It handles asset management, CDN distribution, and real-time updates, so changes can propagate to listeners immediately. Because content lives in the Content Lake as data rather than as rendered pages, the same content can be delivered to multiple channels, websites, apps, and devices, through Sanity's APIs.

Can I customize the Sanity editing interface?

Yes, extensively. Sanity Studio is an open-source, React-based application that developers configure in code. You define schemas, build custom input components, set validation rules, and design editorial workflows specific to a project, so editors get an interface tailored to their content rather than a generic dashboard. This deep customizability is one of the main reasons engineering teams choose Sanity over more rigid, template-based systems.

Want to identify Sanity and the rest of a site's stack automatically? Run any URL through StackOptic at https://stackoptic.com.