A CMS with React needs no custom parser to render your content

What is a React CMS

A React CMS hands content back as data a React component can render directly, instead of an HTML fragment or a proprietary block format. That matters because a React app already renders UI as a tree of components. A CMS that only outputs HTML strings forces a choice: trust that HTML with dangerouslySetInnerHTML, or write a parser that turns it back into components. Neither is built for React. Both treat it as another template target, not the real rendering layer.

Most CMS products predate React. They were built to output whole pages, not small reusable pieces. A React CMS closes that gap by storing content in a format that maps onto JSX with no translation step, usually MDX or a tree of JSON nodes, keeping content structure and component structure in sync. Fields on an entry become typed props, with full TypeScript support end to end. A rich text field becomes a component tree your renderer already knows how to walk.

There's a rendering-time win here too. MDX compiles down to real JSX, so a page built on a React CMS arrives as server-rendered markup on first paint rather than a client-side widget waiting on a script. A blog post or a docs page shows up as markup a browser or a crawler can read immediately, the same way a hand-written component would. No loading skeleton standing in for content.

This matters for react applications rendered on the server as much as ones that hydrate purely client-side, and for most frontend projects today. React remains the most-used JavaScript framework. 81.1% of developers use it. (Source) A CMS built around how React actually renders serves that majority directly, instead of treating React as one output target among several.

Two storage formats show up in practice. Some React CMS products store the component tree as JSON, an array of nodes with a type, props, and children, hand-built from a visual editor. Others, Draftbase included, store MDX: plain Markdown with embedded JSX. MDX has the edge, because it's already a spec with parsers and editor tooling behind it rather than a schema each product reinvents.

Using a headless CMS with React

A headless CMS for React keeps content behind an API and leaves rendering to your app. Your components fetch an entry and render it. No theme layer, no template engine, no page assembled on the CMS side. What varies between products is the shape the content arrives in, and that shape decides how much rendering code you end up owning.

For a React website, the field that settles it is rich text. Contentful returns a JSON node tree; Sanity returns Portable Text. Either way you write a walker that maps every node type to a component, then extend it the next time an editor wants a new block. Draftbase stores that field as MDX and renders it with <MDXContent>. Same API-first setup. No walker.

Then there's cost. Self-hosting Strapi, Payload, or Directus gives you a free and open-source headless CMS, and you pay for it in hosting, upgrades, and backups instead. Draftbase's Hobby plan is free and hosted, with paid plans from $49/mo. If you'd rather build a CMS with React yourself, read the next section first.

Building a CMS with React vs. using one

Teams building React content today usually pick one of three approaches. The first is MDX files committed straight to the repo: no database, no editor UI, content ships with a deploy. That works fine until a non-developer needs to edit copy, and every typo becomes a pull request. The second is a generic headless CMS with a React SDK layered on top. Content arrives by API, but the rich text field arrives as a proprietary JSON blob you still have to convert to JSX yourself. Usually it's a tree of typed nodes: a paragraph node, a heading node, an embed node. Each vendor picks its own shape, so the renderer you write for one CMS won't carry over to the next.

Draftbase is the third path. It keeps the git-free editing of a headless CMS. But it stores rich text as plain MDX, so <MDXContent> can render an entry the moment it's fetched. Component reuse works exactly as it does in your repo: drop your own <Callout> or <ProductCard> into an article. Content stays editable outside a deploy.

None of these approaches is always right. Repo-committed MDX still fits a docs site run entirely by engineers, where a pull request is the natural review step. A React CMS earns its place once marketing, support, or content teams need to publish without a developer in the loop, and the result still has to look like the rest of the product rather than an embedded iframe.

The generic-headless-CMS path looks fastest at the start and usually costs the most over time. The first integration is a weekend of work: install an SDK, map a few fields, ship a page. Then the renderer for the rich-text format starts growing, picking up a new case for every block type an editor adds, until it's a small parser your team maintains forever.

Side by side, the three approaches differ on two things. Who edits content, and how much rendering code your team has to maintain.

The row that tends to surprise teams is type safety. It looks like a nice-to-have. Until a template gains a field mid-project. The generic-CMS column's any lets that change compile cleanly. It quietly breaks at runtime instead. Generated types turn that into a build-time error. The rendering row carries a similar hidden cost. A custom renderer isn't a one-time build. It's an ongoing job that grows every time an editor asks for a new content block.

How Draftbase implements React-native content

React support here is the storage format, plus two packages that move content into your app. The four pieces below cover the whole path: database entry to typed, rendered component. Your team doesn't assemble that path from smaller parts.

85% of new React projects now start with Next.js. That's from the State of React 2025 survey, reported by Strapi. (Source) That default matters for a CMS's SDK. A fetch-based client with no client-only code runs unmodified inside a Server Component. A client built around browser globals doesn't. The same survey found 48% of React developers already use React 19 daily. 41% are still on React 18. (Source) Draftbase's SDK targets both. No version-specific build needed. It's just fetch calls and plain objects. That same SDK works outside React too — see the full framework support list for React Native, Svelte, Vue, and more.

Draft content follows the same path. Entries hold a draft state and a published state, and a Server Component previewing a draft calls cms.entries.get(id), the management-scoped read, rather than the delivery-scoped getEntry. Both return the same field shape, so one <MDXContent> call serves the live page and the preview. No second rendering path to maintain.

Here is the whole path in one file. A Server Component fetches an entry through the typed delivery client and renders its rich text field, with one of your own components made available by name inside the content:

import { notFound } from 'next/navigation';
import { createClient } from '@draftbase/sdk';
import { MDXContent } from '@draftbase/renderer';
import { Callout } from '@/components/Callout';

const draftbase = createClient({ apiKey: process.env.DRAFTBASE_DELIVERY_KEY! });

interface PostFields {
    title: string;
    body: string;
}

export default async function Post({ params }: { params: { id: string } }) {
    const entry = await draftbase.getEntry<PostFields>(params.id);
    if (!entry) notFound();

    return (
        <article>
            <h1>{entry.fields.title}</h1>
            <MDXContent source={entry.fields.body} components={{ Callout }} />
        </article>
    );
}

No client component, no data-fetching hook, no rich-text walker. getEntry returns null for an entry that isn't published, which is why the notFound() line is there rather than a runtime guard around every field. Generate PostFields from your template with the SDK's codegen and even that interface stops being hand-written.

Schema changes flow through the same generated types. Add a field to a template in the dashboard and it's there the next time you run codegen, typed as optional until it's marked required. No manual mapping file to update on the frontend. And when a component expects a field the schema no longer has, you get a type error at the exact spot that needs fixing, not a blank space on a live page.

React CMS with the Next.js App Router and Server Components

In the App Router, a page is a Server Component by default, so fetching content is a plain await in the component body. The SDK is fetch calls and plain objects with no browser globals, so none of it ships to the browser. A CMS client that assumes a browser environment, or that expects a React hook, forces the opposite: a client component, a loading state, and the client bundle to carry both.

Caching is the next decision, and it belongs to your app rather than to the CMS. Three options, cheapest first. Set export const revalidate on the route segment and Next.js rebuilds the page on a timer. Wrap the fetch in unstable_cache to cache one query independently of the page. Or pass cacheTtlMs when you create the client, which caches read responses inside the SDK itself. For content that has to update the moment it publishes, point a publish webhook at a Route Handler that calls revalidatePath. No redeploy, no polling.

<MDXContent> is an async component because compiling MDX is asynchronous, and an RSC is allowed to await inside its own body. That is the only place this matters: outside RSC — client-side React, a Remix loader — call compileMDX(source) yourself, then render the Content component it returns. Same compilation, one extra line. React Native is the same pattern through its own entry point, @draftbase/renderer/react-native, which also ships default component mappings so it doesn't need one.

'use client' comes in for interactivity inside content, not for the content itself. A <Callout> made of markup stays a Server Component. A tabbed code sample or a pricing slider needs state, so that component carries the directive and gets passed in through the same components map. The page around it stays server-rendered, and only the interactive component reaches the browser.

Best React CMS options compared

Nine products that a React team realistically shortlists. The column that decides the most work is rich text storage: it sets whether you render an entry with one component call or maintain a mapping layer per block type. Prices are the cheapest paid tier at the time of writing, taken from each vendor's own pricing page. Check them before you budget.

Two rows are worth reading against us rather than for us. Payload runs inside your Next.js app, so there is no API boundary to cross at all — if that shape fits your project, it beats any hosted CMS on integration distance. And Strapi self-hosted costs nothing in license fees and keeps the database in your own infrastructure, which Draftbase does not offer.

The one claim we will make outright: every other row stores rich text in a format that needs a mapping layer before React can render it, and Draftbase stores MDX, so a component with typed props written by an editor renders in a Server Component with no walker in between. For a full roundup with feature-by-feature scoring, read the best headless CMS for 2026. This table stays a scannable shortlist.

Common pitfalls building a React CMS integration

The most common mistake: treating a CMS's rich text field as safe HTML. Safe enough to drop straight into the page. Most CMS output isn't sanitized for that. Doing it anyway opens a security hole the moment an editor pastes in untrusted markup. It also blocks component reuse. A raw HTML string can't render a live React component the way JSX can. MDX compiled through a real evaluator, like <MDXContent>, avoids both problems. It parses content as MDX, not trusted HTML. It only renders the components you explicitly pass in.

The second mistake is fetching content on every render with no caching. Say a page has a hero entry, a related-posts list, and an author record. That turns into a waterfall of API calls. One round trip per section. The third mistake is hand-writing TypeScript types for CMS fields. Then letting them drift from the real schema once a field gets added. That mismatch usually shows up as undefined on a live page. Generating types from the schema, the way @draftbase/sdk's codegen does, keeps the two in sync on its own. No one has to remember to update a type file by hand.

Two complete Next.js sites, not starter templates

A storefront and a course platform, each a public repo with a live deployment you can open before cloning. Both run on the App Router: <MDXContent> renders rich text as a Server Component, and generateStaticParams enumerates every page at build time. Nothing is stubbed out.

npx @draftbase/create my-site