When a project genuinely wants a headless CMS — not a headless front end stuck onto a traditional CMS, but a content backend built for headless from the ground up — the three platforms that come up in 2022 are Sanity, Contentful, and Strapi. We have shipped client projects on all three this year. Here is the working comparison we use in discovery calls.
Sanity: the developer’s choice that editors warmed up to
Sanity treats content as JSON, treats the schema as code, and gives editors a customizable editing interface called the Studio. The Studio is itself a React application that the developer configures and deploys alongside the project.
The developer experience is the best of the three. Schema definitions live in version control. Schema changes flow through pull requests, code review, and deploys like any other code. The GROQ query language is genuinely capable for complex content shapes. The Sanity APIs are fast.
The editor experience was rough through 2021 but is now genuinely good. The Studio can be customized — custom input components, conditional fields, references with previews, structured rich text through Portable Text — to a level the other two platforms cannot match. Editors who use Sanity regularly tend to prefer it once they have spent a few weeks in it.
The catch is that the Studio configuration is your responsibility. A developer has to wire up the inputs, the structure, the document actions. There is no out-of-the-box editing UI in the way Contentful provides one. For a project with a developer team, this is a feature. For a project that wants a finished CMS day one, it is a cost.
Contentful: the enterprise default
Contentful is the most mature of the three. It has been around since 2013. It has the largest enterprise customer list, the most complete role-based access control, the most predictable hosted infrastructure.
The schema is defined through the web UI, not as code. Field types, validations, references — all configured in the Contentful app by an admin user. There is a Contentful CLI for syncing schema between environments, but the source of truth is the cloud schema, not a file in your repo.
The editor experience is polished and consistent. The interface looks the same on every project. The learning curve for a new editor is short. The collaboration features — workflow, scheduled publishing, content preview to a connected front end — are mature.
The pricing tier matters. The free tier is generous but the next jump is to a ‘community’ tier at around 489 dollars a month, and the enterprise tier is a real enterprise tier with real enterprise pricing. Sanity’s pricing is more linear and lower at the small-business end.
Strapi: the self-hosted option
Strapi is open source, self-hosted (or hosted on your own infrastructure), and gives you a Node.js application you run wherever your other services run. The schema is defined through the admin UI, similar to Contentful, but the resulting code is generated into your repository.
The developer experience is good. The customization API is real — you can write custom controllers, services, lifecycle hooks, and middleware in Node. The integration with the rest of your stack, if your stack is already Node, is tight.
The editor experience is functional but plain. Strapi’s UI does not match the polish of Contentful’s. Custom field components are possible but the API is younger than Sanity’s Studio. Editors who have used Contentful previously tend to find Strapi a step down on the editing day-to-day.
The cost story is the most attractive of the three. There is no per-seat or per-content-entry pricing because the platform is on your servers. The operational cost — running the Strapi instance, managing its database, updates, security patches — is on you. For a team that already runs Node infrastructure that is a small additional load. For a team that does not, it is a real cost.
How we pick
For a project with a real engineering team, a need for highly custom editor workflows, and a developer-led culture: Sanity. The Studio customization is the differentiator.
For an enterprise project with multiple editorial teams, complex governance requirements, and a ‘we want to know who owns this software’ decision lens: Contentful. The maturity and the support story are worth the price.
For a project with a strong Node infrastructure preference, data residency requirements that rule out US-hosted SaaS, and a team that wants to own the stack: Strapi. The self-hosted model is the differentiator.
The three things every headless CMS choice needs
Regardless of which platform you pick, the same three things make or break the project.
First, the content model. The schema you define on day one will outlive every other decision in the project. Spend more time on it than you think you need to. Specifically, get the reference fields right — most rebuilds we see on headless projects come from a schema that treated references as nice-to-haves rather than structural.
Second, the preview story. Editors expect to see what their content will look like before they publish. All three platforms support content preview through a connected front end, but the wiring is non-trivial. Plan for one to two weeks of preview-flow engineering on top of the basic content model.
Third, the migration path. The content in your CMS will need to be moved at some point — to a new instance, a new platform, or back to a monolithic CMS if the project changes direction. All three platforms have export tooling, but the cleanliness of the export varies a lot. Sanity’s JSON-based export is the easiest of the three to work with downstream. Contentful’s is more verbose. Strapi’s depends on your database.
The trend
The interesting shift in 2022 is that the headless CMS market has stopped being a niche. Marketing teams now ask about headless CMS choices by name. The vendors are competing on editor experience as much as on developer experience, which is the right direction for the long-term health of the category. Whichever platform a project picks, the platform is no longer the most expensive part of the project. The integration into a working editorial workflow is.