A headless CMS separates content from presentation
It stores structured content and serves it over an API. Any frontend can render it. A React app, a mobile client, a third-party app. Draftbase is a headless CMS built around MDX, not a proprietary rich-text format.
import { cms } from "@/lib/cms/client";
import { MDXContent } from "@draftbase/renderer";
const post = await cms.entries.get("blogPost", id);
// post.fields.content is typed + ready for
<MDXContent source={post.fields.content} />Content is MDX from the start. The SDK ships typed entries and the React package renders them — no custom renderer to maintain.
What "headless" actually means
A CMS like WordPress ties the content editor to a rendering engine. Change the template, and every page changes with it. But you can't reuse that content elsewhere without scraping HTML. A headless CMS removes the rendering engine entirely. Content lives as plain data behind an API. Presentation becomes the frontend team's job, not the vendor's.
This split matters more as teams ship to more places. A product page might render on a Next.js site. Or inside a native app. Or in a partner's store. A headless CMS serves the same content to all three. Through one API. No need to keep three copies in sync.
The global headless CMS market was worth about $1.75 billion in 2025. It's set to grow at a 17.5% yearly rate through 2033, per Grand View Research. (Source) Teams are leaving big, all-in-one CMS platforms. The API-first model fits how modern sites ship today.
Headless vs. decoupled vs. composable CMS
These terms get used as if they mean the same thing. But they cover different scopes of one idea. Headless means content has no built-in frontend. You get it only through an API. Decoupled is a close cousin. The CMS may ship a default frontend, but you can skip it. Composable goes further still. It applies that same idea to the whole stack: search, commerce, personalization. No single vendor owns the whole thing.
Draftbase sits squarely in the headless camp. There is no built-in renderer to skip. Content is served through a REST delivery API and a GraphQL endpoint. Your app owns every pixel.
How Draftbase implements headless architecture
Schema-driven templates
Every collection starts as a typed template: text, rich text, media, references, JSON. Validated on write, not guessed on read.
API-key delivery API
A read-only delivery endpoint, separate from the management API, serves published entries to any frontend. No write access exposed.
MDX-native content
Rich text fields store plain MDX, not a proprietary JSON document. Render it with @draftbase/renderer. No custom parser needed.
Draft/publish + revisions
Entries hold draft and published states. Every save keeps a full history. A bad edit is a rollback, not a crisis.
This is what "API-first" looks like in real life, not just in marketing copy. The write API needs a login. The read API needs a key. These are separate. That's also why Draftbase can safely fire webhooks on publish without touching your write path.
Why teams move off traditional CMS platforms
69% of headless CMS users shipped faster after leaving an old platform. That's from a Storyblok survey. (Source) The pattern shows up across industries. 72% of teams surveyed by Content Science had a hard time reaching every channel. Their old CMS got in the way. (Source) A headless model fixes this. One content record, many delivery targets. No re-platform needed when a new surface shows up.
Here's the angle most comparisons skip. The real cost of an old CMS isn't the license. It's the custom rendering layer every generic headless CMS still makes you build for rich text. Draftbase skips that step. MDX is the native format. The content is ready to render in React from the moment it's written.
Headless CMS options at a glance
| Capability | Traditional CMS | Generic headless CMS | Draftbase |
|---|---|---|---|
| Content delivery | Server-rendered templates | REST/GraphQL API | REST + GraphQL delivery API |
| Rich text format | HTML in the DB | Proprietary JSON document | Plain MDX string |
| Frontend renderer | Built into the CMS | You build one | Ships as @draftbase/renderer |
| Publish → sync | Cache purge, manual | Webhooks, self-managed | Webhooks on every status change |
Common pitfalls when adopting a headless CMS
Teams that struggle with a headless move usually hit one of three walls. First, they model content around the old page templates, not the real data shape. That just moves the old coupling up one layer. Second, they treat the API as an afterthought. Then they find slow query bugs once the site goes live. Third, they pick a rich-text format that needs a custom renderer. That renderer becomes its own maintenance burden.
The fix for the first two: model templates around what the data actually is. A blog post. A product. An author. Not a page layout. Use the GraphQL endpoint when a view needs several related entries in one trip. The fix for the third: pick a CMS where rich text already fits your frontend. That's the exact problem MDX storage solves.
Try headless content modeling
Define a template. Publish an entry. Pull it through the delivery API. All in one sitting.
Frequently asked questions
What is a headless CMS?
A headless CMS stores and manages content separately from the frontend that displays it, exposing content through an API instead of a fixed template engine. Any frontend — React, mobile, or a third-party app — can pull the same content.
Is a headless CMS the same as a composable CMS?
No. Headless describes the decoupling of content from presentation. Composable extends that idea to the whole stack — swapping in commerce, search, and personalization services independently instead of relying on one vendor for everything.
Does a headless CMS slow down page load?
No — decoupled architecture generally improves load time, since the frontend can be statically generated or edge-rendered instead of running server-side template logic on every request. Good Largest Contentful Paint scores rose from 44% of mobile pages in 2022 to 62% in 2025 as sites moved to this model. (Source: HTTP Archive Web Almanac)
Can a headless CMS support MDX and React components directly?
Most generic headless CMSs store rich text as a proprietary JSON document that you have to write a custom renderer for. Draftbase stores content as raw MDX strings and ships a React package, `@draftbase/renderer`, that renders it — so there's no custom renderer to build or maintain.
How do I migrate from a traditional CMS to a headless one?
Model your existing templates as templates (fields + validation) first, then migrate content record by record via the delivery API rather than a one-shot database dump — this catches schema mismatches early instead of after go-live.