Sanity vs Contentful: A Detailed Comparison

Sanity vs Contentful comes down to where your content model lives and how much control you want. Both are hosted, API-first headless CMSs, but Sanity defines its schema in TypeScript code, queries content with GROQ and gives you an open-source, fully customisable React editing app called Sanity Studio. Contentful defines its content model in a web interface, delivers content through REST and GraphQL APIs, and offers a polished, fixed editing app that you extend with apps. Choose Sanity if your team is developer-led and wants schema-as-code, flexible queries and a tailored editor. Choose Contentful if you want an established enterprise platform that non-developers can configure without touching code.

Both platforms are mature and widely used, so the decision is rarely about whether one "works". It's about fit: how your developers like to work, how your editors like to work, and how the pricing scales with your team. This comparison covers content modelling, querying, the editing experience, rich text, images, extensibility, environments, pricing and migration, with code examples from each side.

Sanity and Contentful at a Glance

Area	Sanity	Contentful
Hosting	Hosted Content Lake, Studio can be self-hosted or deployed to Sanity	Fully hosted (SaaS)
Content model	Defined in code (defineType, defineField)	Defined in the web app or with migration scripts
Query language	GROQ, plus an optional GraphQL API	REST (Content Delivery API) and GraphQL
Editing app	Sanity Studio, open-source React app you configure	Contentful web app, extended with apps
Rich text	Portable Text (JSON)	Rich Text field (JSON)
Real-time collaboration	Built in, with presence and live updates	Supported, with a more traditional entry-locking feel
Environments	Multiple datasets per project	Spaces and environments
Free tier	Yes	Yes
Paid entry point	Per-seat pricing on Growth	Fixed monthly plans, higher entry cost

If you're new to Sanity, the beginner's guide to Sanity explains the core ideas before you dig into this comparison.

Content Modelling: Code vs Clicks

This is the biggest difference between the two.

Sanity: Schema as Code

In Sanity, a content type is a TypeScript file in your Studio project. You review it in pull requests, share it between projects and version it with Git:

// schemaTypes/post.ts
import { defineField, defineType } from 'sanity';

export const post = defineType({
  name: 'post',
  title: 'Post',
  type: 'document',
  fields: [
    defineField({
      name: 'title',
      type: 'string',
      validation: (rule) => rule.required().max(80),
    }),
    defineField({
      name: 'slug',
      type: 'slug',
      options: { source: 'title' },
    }),
    defineField({
      name: 'author',
      type: 'reference',
      to: [{ type: 'author' }],
    }),
    defineField({
      name: 'body',
      type: 'array',
      of: [{ type: 'block' }, { type: 'image' }],
    }),
  ],
});

Because it's code, you can compose schemas from reusable pieces, generate fields with functions, add conditional logic with hidden and write custom validation in plain JavaScript. The post on creating your first schema walks through this in detail.

The Content Lake itself is schemaless. The schema describes what Studio shows and validates, but the stored documents are just JSON. That makes changes cheap: adding a field is a code change, not a migration.

Contentful: Content Types in the Web App

In Contentful, you create content types in the web app by adding fields such as Short text, Rich text, Media and Reference. Field validations, help text and appearance are set through the interface. Non-developers can model content without a code editor, which some organisations see as a big advantage.

For repeatable changes across environments, Contentful offers a migration CLI and the Content Management API, so you can script content type changes:

// migrations/01-create-post.js
module.exports = function (migration) {
  const post = migration.createContentType('post').name('Post');
  post.createField('title').name('Title').type('Symbol').required(true);
  post.createField('slug').name('Slug').type('Symbol');
  post
    .createField('author')
    .name('Author')
    .type('Link')
    .linkType('Entry')
    .validations([{ linkContentType: ['author'] }]);
  post.createField('body').name('Body').type('RichText');
};

Contentful's model is enforced by the platform. If a content type says a field is required, the API respects that. Sanity, by contrast, only enforces validation in Studio, which gives you flexibility but means scripts and imports must be careful.

Querying Content

GROQ in Sanity

Sanity's query language, GROQ, lets you filter, join and reshape data in a single request. You ask for exactly the fields you want, follow references with -> and rename fields on the way out:

*[_type == "post" && defined(slug.current)] | order(publishedAt desc)[0...10]{
  title,
  "slug": slug.current,
  "authorName": author->name,
  "imageUrl": mainImage.asset->url
}

From a Next.js App Router project, you'd run that with next-sanity:

// src/sanity/client.ts
import { createClient } from 'next-sanity';

export const client = createClient({
  projectId: process.env.NEXT_PUBLIC_SANITY_PROJECT_ID!,
  dataset: 'production',
  apiVersion: '2025-10-01',
  useCdn: true,
});

// src/app/blog/page.tsx
import { client } from '@/sanity/client';

const POSTS_QUERY = `*[_type == "post" && defined(slug.current)]
  | order(publishedAt desc)[0...10]{ title, "slug": slug.current }`;

export default async function BlogPage() {
  const posts = await client.fetch<{ title: string; slug: string }[]>(POSTS_QUERY);
  return (
    <ul>
      {posts.map((post) => (
        <li key={post.slug}>
          <a href={`/blog/${post.slug}`}>{post.title}</a>
        </li>
      ))}
    </ul>
  );
}

Sanity also offers a GraphQL API you deploy from your schema, but most Sanity projects use GROQ because it's more expressive. The GROQ vs GraphQL post explains the trade-offs.

REST and GraphQL in Contentful

Contentful's Content Delivery API is REST-based, with query parameters for filtering and an include parameter that resolves linked entries. The JavaScript SDK wraps it:

import { createClient } from 'contentful';

const client = createClient({
  space: process.env.CONTENTFUL_SPACE_ID!,
  accessToken: process.env.CONTENTFUL_DELIVERY_TOKEN!,
});

const entries = await client.getEntries({
  content_type: 'post',
  order: ['-fields.publishedAt'],
  limit: 10,
  include: 2,
});

Contentful also has a GraphQL Content API, which many teams prefer for typed, nested queries. Both are reliable and well documented. The difference is that GROQ can reshape and compute values server-side, while Contentful's APIs return entries closer to how they're stored, with links you resolve in your code or through include.

The Editing Experience

Sanity Studio is a React application you install in your project. You decide the document lists, the order of fields, custom inputs, previews and even whole custom tools. Editors see changes from colleagues in real time, with avatars showing who's editing which field. The Sanity Studio walkthrough shows what editors see day to day.

Contentful's web app is consistent and familiar, with entry editors, a media library, tasks, comments and workflows on higher tiers. You can't restructure the app itself, but you can add custom field editors, sidebar widgets and full-page apps through the App Framework.

In practice:

• Choose Sanity if your editors would benefit from a workspace designed around your content, such as a structured navigation for a large site or custom inputs for product data.
• Choose Contentful if you want a standard interface that works the same across many projects and teams with minimal setup.

Rich Text

Both store rich text as structured JSON rather than HTML, which is the right choice for a headless CMS.

• Sanity: uses Portable Text, an open specification. You can embed custom objects such as call-outs, code blocks or product cards directly in the text, and render them with @portabletext/react or similar libraries. See what is Portable Text for how it works.
• Contentful: uses its own Rich Text format, also JSON, with embedded entries and assets. You render it with @contentful/rich-text-react-renderer.

Sanity's approach is more flexible because any object type you define can live inside a block of text. Contentful's is simpler to start with but more fixed.

Images and Assets

Both include an image CDN with on-the-fly transformations. Sanity stores hotspot and crop data that editors set in Studio, and its URL builder applies them automatically:

import { createImageUrlBuilder } from '@sanity/image-url';
import { client } from './client';

const builder = createImageUrlBuilder(client);

export const urlFor = (source: Parameters<typeof builder.image>[0]) =>
  builder.image(source);

// urlFor(post.mainImage).width(1200).height(630).auto('format').url()

Contentful's Images API supports resizing, cropping, format conversion and focus areas through URL parameters. For most sites, both are more than enough. Sanity has the edge for editor-controlled cropping across many aspect ratios.

Extensibility and Customisation

Need	Sanity	Contentful
Custom field input	Write a React component and set components.input	Build an app with the App Framework
Custom document actions	Configure document.actions in sanity.config.ts	Apps and workflows
Plugins	npm packages added to plugins	Apps from the marketplace
Restructure the editor	Structure Builder with structureTool	Not possible beyond app locations
Webhooks	GROQ-filtered webhooks with custom projections	Webhooks with filters per event

Sanity's plugins are installed like any npm package and added to your config:

// sanity.config.ts
import { defineConfig } from 'sanity';
import { structureTool } from 'sanity/structure';
import { visionTool } from '@sanity/vision';
import { schemaTypes } from './schemaTypes';

export default defineConfig({
  name: 'default',
  title: 'My Site',
  projectId: 'your-project-id',
  dataset: 'production',
  plugins: [structureTool(), visionTool()],
  schema: { types: schemaTypes },
});

Environments and Workflow

Sanity projects contain datasets, which are separate content stores such as production and staging. Your schema lives in code, so you deploy schema changes with your Studio and test them against a staging dataset first.

Contentful has spaces and environments within a space. Environments can be cloned from master, used to test migrations, and then promoted with aliases. It's a well-thought-out workflow for teams that change content models often, especially combined with the migration CLI.

Both support scheduled publishing and content releases on paid tiers, so check the current plan pages for which features are included where.

Pricing

Pricing changes regularly, so always check the official pages before deciding. As of writing:

• Sanity: has a Free plan with up to 20 seats, two public datasets and 10,000 documents. The Growth plan costs $15 per seat per month, adds private datasets, more roles and a higher document limit, and charges for overages. Enterprise is custom. Viewer seats are free. The Sanity pricing guide goes through the limits.
• Contentful: has a Free plan with limits on users, content types, locales and records. Paid plans are priced per month at a fixed tier rather than per seat, and the entry paid plan costs considerably more than a small Sanity Growth team. Premium plans are custom.

For a small team, Sanity is usually cheaper to start and grow with. For a large enterprise, both negotiate custom contracts, so compare total cost against features such as SSO, workflows and support.

Migrating Between Them

Moving from Contentful to Sanity is a common path, and both sides make it manageable:

1. Export your Contentful space with the Contentful CLI (contentful space export), which produces JSON for content types, entries and assets.
2. Recreate the model as Sanity schemas in code. This is a good time to simplify fields that grew messy.
3. Transform entries to Sanity documents with a script, converting Rich Text to Portable Text and links to references.
4. Import with npx sanity dataset import or the client's transactions, uploading assets first so you can reference them.

The reverse is also possible, but Portable Text with many custom blocks may not map cleanly to Contentful's Rich Text, so plan for some flattening.

Which Should You Choose?

If you…	Choose
Want the content model in Git, reviewed like code	Sanity
Need non-developers to create content types	Contentful
Want flexible joins and reshaping in one query	Sanity
Prefer standard REST and GraphQL with strict model enforcement	Contentful
Need a custom editorial interface	Sanity
Want the same interface across many brands and teams	Contentful
Are a small team watching costs	Sanity

---

FAQ: Sanity vs Contentful

---

Conclusion

Sanity and Contentful solve the same problem in different ways. Sanity treats content as data shaped by code: schemas live in your repository, GROQ lets you query exactly what you need, and Studio can be shaped around your editors. Contentful treats the content model as platform configuration, with a consistent web app, strong model enforcement and well-established enterprise workflows.

If your team is developer-led and values flexibility and cost control, Sanity is usually the better choice. If you need non-technical teams to own the content model, or you want an interface that stays identical across many projects, Contentful earns its higher price. If you're also weighing a self-hosted option, read the Sanity vs Strapi comparison next.