The best React rich text editor for MDX outputs React, not JSON

What is a rich text editor for React, and why MDX changes the tradeoffs

A React rich text editor lets a writer format text inside a React app: headings, bold, links, embedded blocks. Most popular options store that formatting as a proprietary JSON document. Slate, TipTap, Lexical, and Draft.js all work this way. That document is internal to the editor. It isn't standard markup.

Ask which React rich text editor is best and most answers name a library. That's the wrong first question. Ask what format the content ends up in. The format decides how much work is left after the editor ships.

That JSON document is not directly renderable. Every team using one of these libraries writes a serializer. It walks the document tree and turns it into HTML or React elements. Change the schema and the serializer changes too. Add a callout, a video embed, or a code sandbox, and the serializer needs a new branch. The editor's flexibility becomes the renderer's maintenance burden.

This isn't a knock on those libraries. Slate, TipTap, and Lexical are good at what they're built for. The tradeoff is scope. They solve editing and leave rendering to whoever consumes the output.

MDX is a different kind of output. It's Markdown plus JSX. An editor built on MDX produces content that is already valid, renderable React source. A heading in MDX is a Markdown heading. A custom block is a JSX component, used like any other component in the app.

This is why an MDX-based editor travels well. The same string renders the same way in a blog, a docs site, or a marketing page. It isn't tied to one library's document model. Move it to a different React project and it still renders.

Take a writer embedding a pricing table in a blog post. A JSON-document editor needs a new node type, a UI affordance to insert it, and a serializer branch to render it. In MDX it's one line: <PricingTable plan="pro" />. That component already exists in the app.

The editor still has a learning curve. A writer needs Markdown basics — headings, bold, blockquotes. What's removed is the second curve. No frontend team has to learn a proprietary document schema to display what the writer typed — the only schema is the content type the template already defines, served through the same headless CMS delivery API.

How Draftbase's MDX editor works

Four pieces run end to end, from typing a heading to rendering it in an app. Each is small on its own. Together they remove the renderer-building step.

Custom React components used inside content are registered separately, through the MDX components screen. Each component is defined once, with a typed set of props: string, number, boolean. A writer drops a named component into a block the way they'd type a heading. The field editor validates the props before the entry saves.

None of these four pieces require a separate build step. There's no compiler to configure, no plugin chain to assemble before content becomes usable. Write MDX in the editor, publish the entry, and it's ready for MDXContent to render.

A non-technical writer never sees this plumbing. They see blocks, a toolbar, and a save button. The schema and the component registry work in the background. Nobody learns MDX syntax by hand.

Templates and MDX components are both schema-defined, so edits aren't limited to the editor UI. An agent making MCP-connected edits reads the same schema a human editor fills in. One source of truth for what a valid entry looks like.

What ships in the editor

Nine things a writer can do without a developer opening the repo. Every one of them is in the editor today, not on a roadmap.

Comparing React rich text editor approaches

Every approach to rich text in React sits on one spectrum. How much of the renderer do you build, and how much ships with the editor? The table lines up three common paths on the same four questions.

All four rows show the same pattern. Bring-your-own editors and generic CMS fields push the rendering problem onto the frontend team, later. An MDX editor folds that cost into the editor. You pay it once, not on every project that reuses the content.

Best rich text editors for React, compared

Five real options plus this one. The first four are editor libraries: you install them into an app you already own, and the content stays your problem. That is a feature if you want it, and the reason the last column is not a clean sweep.

Read the fourth column as the whole trade. The libraries win on control and price: MIT-licensed, free forever, running inside your app with no vendor between you and the content. Draftbase is a hosted product, so that independence is what you give up. What you get back is the four jobs the libraries hand you afterwards — storing the content, validating it, versioning it, and serving it to a frontend. If your app already has all four, install Lexical or TipTap and stop reading.

How to add a rich text editor to a React app

Two paths, and the difference isn't the editor. It's what you own after the writer clicks save.

Path 1: install an editor library

Fast to a working toolbar, then the real work starts. The editor hands you a document; where it goes, what makes it valid, and how it becomes React elements are all yours.

const editor = useEditor({ extensions: [StarterKit] });

// Everything past this line is yours to build:
await db.posts.update(id, { body: editor.getJSON() }); // storage
// + validation, revision history, draft/publish, and a
// renderer that walks that JSON back into components

Path 2: use a CMS that ships the editor and the storage together

The editor lives in the dashboard, the content lives behind a read-only delivery API, and the frontend renders the stored MDX directly. Same markup as the React CMS path, because it is the same call.

import { createClient } from '@draftbase/sdk';
import { MDXContent } from '@draftbase/renderer';

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

export default async function Post({ params }) {
    const entry = await draftbase.getEntry(params.slug);
    return <MDXContent source={entry.fields.body} components={{ Callout }} />;
}

Nothing in the second sample parses the content. MDX compiles to JSX, so the framework's existing compiler does that step, and the components map is how your own React components render inside the prose a writer typed.

Common pitfalls with rich text in React

Teams underestimate the renderer-maintenance cost of a JSON rich text format. The editor library is easy to install. The serializer is the part that keeps needing updates. Every new block type a writer asks for is a new branch, shipped by an engineer rather than the writer who needed it.

A common shortcut is rendering CMS rich text with dangerouslySetInnerHTML. That's an XSS risk and a dead end for embedding real components. Injected HTML has no React component boundary. A callout box or an embedded chart becomes static markup at best, an injection vector at worst.

This shows up most often after migrating from a page-builder CMS. The old field stored HTML, the new field stores HTML, and dangerouslySetInnerHTML looks like the fastest way to ship. It works for plain paragraphs. It breaks on anything interactive, because client-side state never survives a round trip through raw HTML.

The fix is a format the framework already understands. That's what an MDX editor gives you by default. No serializer stands between what a writer types and what a browser renders.

A quieter third pitfall: two rich text formats across surfaces. Markdown in the docs site, a proprietary format in the blog. Now you maintain two renderers. MDX is a superset of Markdown, so standardizing on it collapses both into one.

Demand for rich, structured editing keeps growing

The global WYSIWYG editor software market is projected to grow from $236.09 million in 2026 to $416.33 million by 2035, a 6.4% CAGR. (Source) More teams adopting rich editing means more teams hitting the renderer-maintenance problem. A growing market doesn't shrink that problem. It just means more teams find it later, after the editor is wired into production.

MDX files compile to regular JSX at build or request time, per the MDX documentation. No separate runtime interprets them. That's why an MDX-based editor needs no bespoke rendering layer. The compiler step already exists in the framework.

So here's the practical takeaway. Ask what an editor outputs before asking what it can format. An editor that outputs MDX hands off work the framework already does. An editor that outputs a custom document format hands off a project.