Sanity

Founded circa 2016-2017 by Simen Svale Skogsrud, Even Westvang, Oyvind Rostad, and Magnus Kongsli Hillestad in Oslo/San Francisco; publicly launched November 2017. Sources conflict on the exact founding vs. incorporation year (some cite 2016, one company-registry-style source cites October 2018 as the legal incorporation date); no single official Sanity-published timeline page was found confirming this precisely, so treat as approximate.

Split architecture: Sanity Studio is an open-source (MIT), self-hostable React/Vite editing application; Content Lake, the real-time structured-content datastore/backend it talks to, is a proprietary hosted service that cannot be self-hosted. No native frontend/theme rendering is provided; developers build the presentation layer separately (Next.js, Astro, Remix, etc.), which is the defining trait of headless CMS.

False for the platform as a whole, matching how WordPress.com is scored: the Content Lake datastore/backend that every Sanity project requires is closed-source hosted infrastructure with no self-run option. Sanity Studio, the editing UI, is genuinely MIT open source (github.com/sanity-io/sanity).

Free tier is $0 forever (not a time-limited trial): 20 seats (Administrator & Viewer roles only), 2 datasets (public only), 10,000 documents, 1M API CDN requests/mo, 250k API requests/mo, 100GB assets, 100GB bandwidth/mo, 1,000 AI credits/mo.

Not applicable in the same sense as a website builder: Sanity is headless, so 'custom domain' is a frontend concern outside Sanity's own billing (there is no Sanity-hosted public website to attach a domain to). The Free plan ($0) is fully usable for a production Content Lake backing a self-hosted frontend on any domain. Growth tier (functionally the entry paid tier) is $15/seat/month, self-serve, no annual-commitment discount offered on Growth/Free per the pricing page.

Growth plan: $15 per seat/month, up to 50 seats, billed monthly (no annual self-serve discount listed for Growth/Free; only Enterprise customers can arrange annual billing via sales). Adds private datasets, Editor/Developer/Contributor roles, comments, task management, scheduled drafts, 90-day history retention.

Not applicable: Sanity has no native ecommerce product. Commerce is handled via third-party integrations (e.g., official Sanity Connect for Shopify) layered on top of a standard Free/Growth/Enterprise Content Lake plan; there is no separate 'ecommerce plan' or ecommerce-specific pricing tier.

No evidence of an intro-vs-renewal price gap; Growth is a flat $15/seat/month self-serve rate with no discounted first-term/promo pricing found on the official pricing page.

No money-back guarantee or refund policy was found stated on the official pricing page. Self-serve plans (Free/Growth) are usage-based/monthly with no minimum term mentioned, which reduces the practical need for one, but no explicit guarantee is documented.

Developers define content schemas as JavaScript/TypeScript objects; Sanity Studio then auto-generates a structured editing UI (forms, not a page canvas) from that schema. Studio is not a page-layout/drag-and-drop website builder; it is a structured-content editing workbench. A separate optional layer, the Presentation tool, adds click-to-edit and drag-and-drop *section reordering* on top of a developer-built frontend (see design/collaboration notes), but the core editing model is code-first schema definition.

No native drag-and-drop page/layout builder (this is a headless CMS with no page-rendering layer). The optional Presentation tool does support drag-and-drop *reordering of content sections* inside a developer-built live preview, but that is section-arrangement within a pre-built frontend, not visual page construction from scratch.

The Presentation tool's Visual Editing overlays let editors click any element in a live frontend preview (iframe) and jump directly to the corresponding field in Sanity Studio to edit it; true click-to-edit, though it requires the frontend developer to wire up overlay support (stega-encoded fields / data-sanity attributes) rather than working automatically on any arbitrary frontend.

Full document-level History experience: view and (via the History API) restore prior revisions using the document's _rev property. Retention is plan-gated: 3 days (Free), 90 days (Growth), 365 days or custom (Enterprise); the latest published/draft version is always available regardless of plan.

Studio sends edits to the backend as patches/transactions in real time as you type; there is no manual 'Save' button for draft content.

No official native Sanity mobile app for content editing was found; Studio is a responsive web application (self-hosted or on sanity.studio) accessed via browser, not a dedicated iOS/Android app.

Not applicable in the website-builder sense; Sanity has no built-in visual 'templates' to switch between. Content lives independently of presentation, so in principle the same structured content can be re-rendered under an entirely new frontend; but there is no one-click theme-swap mechanism, and changing schemas requires developer migration work.

Editorial judgment: Sanity requires a developer to define schemas in code and build/maintain a separate frontend application before any content team can use it. There is real editorial-side payoff (a clean, fast Studio UI once configured), but initial setup and ongoing schema/frontend maintenance demand real software development skills, unlike a hosted website builder a marketer could configure alone.

Not applicable / not published as a single figure; Sanity ships developer starter templates (Next.js, Astro, Remix, etc. quickstarts) rather than a curated count of visual site templates, since presentation is entirely developer-built and not part of the product.

No, in the website-builder sense; Sanity has no site-rendering layer, so there is no Sanity-native 'upload a font for your site' feature. Fonts are entirely a concern of the developer-built frontend, outside Sanity's product surface.

Not applicable in the visual-builder sense, but scored full-control because responsiveness is entirely up to the developer-built frontend code with zero platform constraints; the opposite of an automatic, platform-managed responsive layout.

Sanity places no restriction on CSS: the entire presentation layer (including all CSS) is written by the developer in the separate frontend codebase. Studio's own admin UI can also be customized/themed via its React-based Studio configuration API.

Same reasoning as custom CSS; the frontend is 100% custom-coded (any JS framework), and Studio itself is extensible with custom React components/plugins.

No native animation/interaction authoring tool; Sanity has no page-design surface. Any animation is implemented by the developer in the frontend codebase, not configured inside Sanity.

No native design-token/global-style system for a rendered site (no site-rendering layer exists). Sanity's schema system defines *content* structure, not visual design tokens; any design-token system lives in the separate frontend codebase.

Editorial judgment: because Sanity imposes zero rendering layer, the frontend developer has complete design freedom (identical to hand-coding), the maximum possible flexibility of any platform in this comparison; at the cost of requiring that hand-coding to exist at all.

Content Lake (the structured-content datastore/API backend) is fully managed/hosted by Sanity on Google Cloud Platform infrastructure, included on every plan including Free. This covers only the content backend, not a rendered website; the frontend must be hosted separately (e.g., Vercel, Netlify, self-managed).

False in the sense that matters: the Content Lake backend (the actual content datastore and APIs) is SaaS-only and cannot be self-hosted on any plan. Sanity Studio, the editing app, IS self-hostable (builds to static files servable anywhere), which distinguishes Sanity from fully closed hosted CMSs; but a working Sanity project always depends on Sanity's cloud.

Global CDN included on all plans for both the API CDN (cached GROQ/content queries) and the image asset pipeline (cdn.sanity.io), infrastructure on Google Cloud Platform.

Content Lake API and asset CDN are served over HTTPS by default; Enterprise adds support for custom CDN domains. (Applies to the Sanity-hosted backend/API only; SSL for the separately hosted frontend is that host's responsibility.)

Sanity Studio itself builds to a static dist/ folder (Vite-based SPA) hostable anywhere. Separately, dataset content can be exported via the CLI (sanity dataset export) as NDJSON + asset files for backup/migration; not a 'static site export' of a rendered website (there is no rendered website in Sanity itself), but full structured-content portability.

May 2026 CrUX data via HTTP Archive CWV Technology Report API (technology name 'Sanity'): combined desktop+mobile good-CWV rate 56.7% (9,020 of 15,918 origins). Desktop 63.5% (4,955 of 7,802 tested), mobile 50.1% (4,065 of 8,116 tested). HEADLESS CAVEAT: this measures real-world sites that use Sanity as a content backend, not a Sanity-rendered output; the actual frontend (framework, hosting, image handling, JS bundle size) is 100% developer-built and varies enormously per site, so this number reflects the *ecosystem* of Sanity-powered frontends (skews toward JS-framework sites, which is a plausible driver of the lower mobile score) rather than any performance characteristic Sanity itself controls.

Native image CDN pipeline (cdn.sanity.io) with on-the-fly resizing, cropping, and automatic format selection (auto=format serves WebP/AVIF/etc. based on browser Accept headers), edge-cached globally. Delivering these optimized URLs in markup is still up to the frontend developer.

Not a platform-native feature; Sanity has no rendering layer, so lazy-loading of images/content is implemented by the developer in the frontend code (trivial to add, but not something Sanity provides or enforces automatically).

Site owners/developers control caching via the API CDN vs. non-cached API endpoint choice, GROQ query design, webhook-triggered revalidation (e.g., Next.js ISR/on-demand revalidation patterns), and image CDN cache behavior; far more caching control than a hosted builder, though it requires developer implementation rather than a UI toggle.

Not a built-in SEO panel (no such UI exists in a headless CMS); but because content schemas are fully custom, developers routinely add title/meta-description fields to document schemas, and the frontend template controls how they render. Marked true/possible via custom schema, not a shipped default.

Sanity ships a native 'slug' field type in the schema system specifically for editable, validated URL slugs, generated from a source field (e.g., title) with manual override.

Not a Sanity feature; redirects are implemented and served entirely by the separately hosted frontend/hosting layer (e.g., Vercel redirects, Next.js middleware), not configured within Sanity itself. Some developers model a 'redirects' document type in Sanity content and consume it from the frontend, but that is a custom pattern, not a native product feature.

Achievable via custom schema fields consumed by the frontend template; no dedicated built-in canonical-tag feature since Sanity renders no HTML itself.

Not a Sanity feature; robots.txt is served by the frontend hosting layer, entirely outside Sanity's product surface.

No native sitemap generation; Sanity provides the content via API; the frontend framework/developer is responsible for generating and serving an XML sitemap from that content.

No automatic schema.org generation. Developers model structured-data fields in the schema and render JSON-LD manually in the frontend template using that content.

No native hreflang feature. Localization is achieved via field-level or document-level content modeling patterns (optionally with official plugins like @sanity/document-internationalization), and hreflang tags themselves must be rendered by the frontend using that locale data.

Achievable via custom schema fields (image, og title/description, etc.) rendered by the frontend template; no dedicated built-in OG panel since Sanity has no page-rendering UI.

Achievable via a custom boolean/schema field consumed by the frontend's meta-robots rendering logic; not a native toggle since Sanity has no concept of a 'page' with rendering settings.

Sanity's native image field type supports an optional alt-text field out of the box (developers can enable/require it in schema configuration).

No pre-built blog engine ships with Sanity; a 'blog' is a custom content model (document type + fields) the developer defines, then renders on the frontend. Official quickstart templates for blogs exist as starting points, but there is no native, ready-to-use blog feature.

This is Sanity's core strength: fully custom document types/schemas defined in code, with typed fields, arrays, references, and validation; essentially unlimited custom content modeling, more flexible than plugin-based custom-post-type systems.

Achieved via native Reference and array-of-references field types linking documents (e.g., a Post referencing Category/Tag documents); not a dedicated 'taxonomy' feature by name, but fully supported and a standard modeling pattern.

Scheduled publishing (schedule a document/Content Release to go live at a future date/time) is a native Studio feature on the Growth plan and above; not available on Free.

Native per-document History experience with restore-to-prior-revision capability; retention window is plan-gated (3/90/365+ days on Free/Growth/Enterprise).

Real-time multiplayer editing with multiple named seats; Free plan supports up to 20 seats (Administrator/Viewer roles only), Growth up to 50 seats with a fuller role set (Editor, Developer, Contributor added).

No native RSS feed generation; like sitemaps, this is left entirely to the frontend developer to build from the queried content, since Sanity has no rendering/output layer.

Multiple content APIs: GROQ query API (read, Sanity's own powerful query language) and REST-style HTTP API, Mutation API and the newer Actions API (both read-write, the latter is what powers Studio's own edits and supports the draft/publish authoring model), plus a GraphQL API that is explicitly READ-ONLY (mutations are not exposed through GraphQL; the Mutation/Actions APIs must be used instead). Live Content API supports real-time subscriptions.

No native ecommerce/checkout/cart functionality. Sanity offers an official 'Sanity Connect for Shopify' integration (syncs Shopify product data into Sanity content for editorial/merchandising use) and community plugins for other commerce platforms, but Sanity itself is not a commerce engine; the actual store/checkout logic lives in the connected commerce platform.(Shopify, Stripe, etc.) or custom-built commerce code.

Not applicable; no native ecommerce product exists to have limits on. Any 'product' document count would just count against the standard document-count plan limit (10k Free / 25k Growth / custom Enterprise).

No native commerce capability of any kind (see ecommerce.native); digital product delivery would require a separate commerce platform integration or fully custom build.

No native subscriptions/recurring billing; would require a third-party commerce/payments platform integrated by the developer.

No native commerce features of any kind; multi-currency selling would be handled entirely by a connected third-party commerce platform.

No native point-of-sale feature; not a commerce platform.

No native cart/checkout functionality exists to recover; would be a feature of whichever third-party commerce platform is integrated.

Full dataset export via CLI (sanity dataset export) as NDJSON documents plus a separate assets folder; a complete, re-importable copy of all content and media, not a partial/collection-by-collection export.

Not applicable in the visual-builder sense (no design to export); scored full because the entire 'design'/presentation layer already lives in the developer's own frontend codebase (e.g., a Next.js repo you own outright), with zero platform lock-in on the presentation side. Sanity Studio's open-source (MIT) code and configuration are also fully yours to take elsewhere.

Not applicable in the typical sense (Sanity hosts no public website), but any domain used with a Sanity-backed frontend is registered/managed entirely outside Sanity, so there is no domain lock-in whatsoever.

The frontend can be hosted anywhere (Vercel, Netlify, self-managed, etc.) with zero Sanity dependency for hosting. Sanity Studio itself is also self-hostable (static build). Only the Content Lake data store remains fixed to Sanity's infrastructure; there is no way to run that part off-platform, though its content is fully exportable (see ownership.content_export).

GROQ query API and REST/Mutation/Actions APIs expose complete read/write access to all content in a dataset (subject to role permissions); no artificial API-level content restriction beyond plan usage quotas (request/document limits).

Editorial judgment: content is fully exportable in an open format (NDJSON) via CLI at any time, the Studio editing app is open-source/MIT and self-hostable, and the frontend is 100% developer-owned code with no platform-specific markup or proprietary rendering. The one real lock-in point is Content Lake itself, which cannot be self-hosted or exported to a functionally equivalent open-source datastore; migrating means re-importing NDJSON into a different backend and re-wiring queries, real work but far short of the all-or-nothing lock-in of a closed page-builder SaaS.

GROQ API, REST/HTTP API, Mutation API, Actions API, read-only GraphQL API, and Live Content API for real-time subscriptions; an unusually rich public API surface even by headless-CMS standards.

Native outgoing webhooks on dataset changes (configurable via sanity.io/manage, CLI, or API) with GROQ-based filtering/projections; no plan gating found documented.

Not applicable in the embed-widget sense; the entire frontend is custom code by definition (headless architecture), and Sanity Studio itself accepts custom React component/plugin code with no plan restriction.

Full-featured official CLI: project init, local dev server, Studio build/deploy, dataset import/export, GraphQL API deploy, schema/TypeScript type generation, webhook management, API token management, CI/CD-friendly auth via SANITY_AUTH_TOKEN.

No official native Zapier or Make app was confirmed in Sanity's own plugin/integration directory during this research pass (the Exchange lists developer/framework integrations like Vercel and Mux prominently, not Zapier/Make); webhook-based custom automation is the documented path to third-party workflow tools instead.

No AI website/page generation; there is no site-rendering layer for AI to generate into. AI features are scoped to content operations, not site building.

Sanity Canvas is a freeform AI writing surface that turns loose notes/briefs into structured content matching the project's schema. Separately, Agent Actions (Generate, Transform, Translate) are schema-aware AI APIs for drafting/rewriting content, validated against the Studio schema automatically. Both consume the plan's monthly AI credits (1,000/mo on Free and Growth, overage at $0.05–$1.00/unit).

No definitive official statement found on native AI image generation/tagging within Sanity's own product (as opposed to third-party plugins like 'Lamina' for AI video/image generation listed on the Exchange, which is a community integration, not a native Sanity feature). Not verifying yes/no without a clearer first-party source.

No dedicated native AI SEO auditing/assistance feature found (unlike, e.g., Webflow's AEO agents); Sanity's AI focus is content generation/transformation/translation via Canvas and Agent Actions, not SEO-specific tooling. Any SEO use would be a developer building it on top of Agent Actions/Canvas primitives, not a shipped feature.

Default roles: Administrator (full read/write + settings), Editor (edit existing datasets, limited settings), Contributor (draft-only, no publish), Viewer (read-only, doesn't count toward paid seats unless given another role), Developer (read/write + dev settings). Custom roles with GROQ-filtered, user-attribute-parameterized permissions are Enterprise-only. Free plan is restricted to Administrator/Viewer only; Growth unlocks the fuller role set.

Real-time multiplayer editing is a core, long-standing Sanity Studio feature; multiple editors can work in the same document simultaneously with live sync, not just locking/conflict warnings.

Content Releases (bundling changes for scheduled/reviewed publish) plus Comments and Tasks (assignable to-dos on documents) provide native editorial workflow tooling on Growth and above; not available on Free.

No distinct 'staging environment' concept at the Content Lake level (drafts vs. published documents serve this role within a single dataset), but the Presentation tool provides a live, real-time preview of unpublished/draft content rendered on the actual frontend. Separate datasets can also be used to simulate staging/production splits as a custom pattern.

Native in-document commenting (thread-style comments tied to specific fields), a Growth-plan-and-above feature.

Full audit trail/audit log and History API access to every revision is called out as an Enterprise-plan feature ('complete document histories,' 'audit logs, audit trail and history API'); not available at that depth on Free/Growth, which get only their tier's shorter History retention window.

24/7 incident response and monitoring is called out specifically as an Enterprise-plan benefit; not available on self-serve Free/Growth (even with the paid Dedicated Support add-on, which is not documented as 24/7).

Editorial judgment: Sanity's documentation is unusually deep and well-organized for a developer product; separate reference sections for Studio, Content Lake, APIs/SDKs, CLI, GROQ, migrations, and framework-specific visual-editing quickstarts, plus an active 'Sanity Answers' community Q&A corpus, all linked from a single docs hub.

Automatic daily backups are an Enterprise-plan feature (365-day daily retention, plus 2 additional years of weekly backups, stored in offsite third-party storage); restore is via CLI download + import. Free/Growth customers without this feature must self-manage backups via the CLI's manual dataset export command.

No dedicated built-in accessibility-checker/audit tool was found in Sanity's official docs during this research pass. As a headless CMS with no rendering layer, page-level accessibility (alt text presence aside, which is schema-supported; see seo.image_alt_editable) is largely the responsibility of the developer-built frontend, not something Sanity itself audits.

Not a single native toggle. Sanity documents two supported content-modeling patterns for multilingual content (field-level arrays or document-level per-language documents) plus two official plugins (@sanity/document-internationalization, sanity-plugin-internationalized-array) to streamline the authoring UI; genuinely well-supported, but requires schema design decisions and/or a plugin rather than a built-in 'add a language' switch.

Multiple supported paths: manual translation via document duplication, AI-powered translation via the Agent Actions Translate action / AI Assist plugin (one-click), and professional-service integrations (Transifex, Smartling adapter plugins) plus webhook-based routing to external TMS platforms.

No native hreflang or locale-URL feature (Sanity has no URL routing layer at all; see seo.hreflang and seo.url_structure_constraints). Per-locale SEO is achievable only by the frontend developer building it from Sanity's localized content data.

No official documentation found confirming native RTL handling for either Studio's editing UI or delivered content; the localization docs reviewed did not address RTL. Any RTL rendering (dir="rtl" etc.) would be implemented by the frontend developer.