A content model can be flawless, an API blazing fast, and an AI pipeline state-of-the-art — and the whole CMS will still fail if the people who write in it dread opening it every morning. This chapter makes the vague "must be easy to use" requirement concrete. It covers the three editing paradigms (structured, WYSIWYG, and visual), the four rich-text frameworks you will actually choose between in 2026 (Tiptap/ProseMirror, Lexical, Plate/Slate, and BlockNote), live preview and inline validation, media insertion, AI-in-the-editor, the role and permission model that protects non-technical editors from themselves, and the central engineering decision: build the editor or adopt one.
Editors come in three families, and the choice of family is more consequential than the choice of library inside it.
| Paradigm | What the editor sees | Stored as | Strength | Weakness |
|---|---|---|---|---|
| Structured / field-based | Discrete, typed fields and blocks (title, hero, body, CTA) | JSON tree (e.g., Portable Text), typed records | Clean data, multi-channel reuse, AI-readable | Editors can't "see the page" while writing |
| WYSIWYG rich text | A document that looks roughly like the output | HTML or a rich-text JSON document | Familiar (Word/Google Docs feel) | Mixes content with presentation; hard to reuse |
| Visual / on-page | The actual rendered page, click-to-edit | Whatever the CMS stores, mapped back via source links | Marketers love it; instant context | Couples content to one layout; brittle |
For an AI-native CMS, the bias should be toward structured content with a rich-text field inside it, not a single free-form WYSIWYG blob. Sanity's own guidance captures why: "When an AI agent reads or writes content, unstructured HTML or Markdown is genuinely harder to reason about. Portable Text's JSON structure gives agents something they can work with precisely — the semantic intent of each block is explicit, not implied by markup conventions" (Sanity, , 2025). An LLM asked to "rewrite the second paragraph and leave the pull-quote alone" can address a structured block by id; against an HTML soup it must parse, guess, and re-serialize, losing fidelity each round-trip.
The pragmatic 2026 answer is a hybrid: typed top-level fields for everything structured (SEO, hero, references, CTAs), and one or more rich-text fields for prose, where the rich text itself is stored as a structured tree (Portable Text / ProseMirror JSON / Lexical state) rather than HTML. This gives you the AI-friendliness of structure and the writing comfort of rich text in the same document.
Inside that rich-text field sits a JavaScript editor framework. In 2026 the realistic shortlist is four. (Per Liveblocks' 2025 framework survey and BuildPilot's 2026 comparison.)
| Framework | Foundation | Bundle (core) | Model | Best for | License |
|---|---|---|---|---|---|
| Tiptap | ProseMirror | ~moderate, modular | Headless, 50+ extensions | The default "fastest path to production" | MIT core; paid Cloud/Pro features |
| Lexical | Built by Meta, standalone | ~22 KB core | Headless, performance-first | Huge docs, mobile, scale | MIT |
| Plate | Slate | Component-heavy | Headless + shadcn/ui components | React + shadcn/ui + "own the components" | MIT |
| BlockNote | ProseMirror + Tiptap | Batteries-included | Block-based, Notion-style, styled UI out of the box | Fastest Notion-style editor with minimal code | MPL-2.0 core; GPL-3.0 "XL" packages |
| ProseMirror (raw) | itself | small | Low-level toolkit | Maximum control, custom schemas | MIT |
Tiptap is the consensus default. Built on ProseMirror, it ships 50+ official extensions (tables, mentions, code blocks, task lists, collaboration) with strong docs and interactive examples; reviewers in 2025–2026 repeatedly call it "the fastest path to a production editor" and "the most well-rounded" choice. The tradeoff is that ProseMirror's underlying mental model (schema, transactions, plugins) is real and you eventually meet it; and several of Tiptap's most attractive pieces — Collaboration, Comments, Content AI — are paid cloud or Pro features.
Lexical is the performance champion: ~22 KB core, minimal DOM operations, and it powers the editors across Facebook, Instagram, and WhatsApp Web. Choose it when documents get very large, when mobile/resource-constrained targets matter, or when you want a fully MIT, vendor-neutral base. The cost is maturity and ecosystem: you build more yourself, and the community is younger than ProseMirror's.
Plate builds on Slate and is the natural fit for teams already on React + shadcn/ui. Its "component ownership" model means you copy the editor components into your codebase (like shadcn) and own them outright — great for deep customization, more upfront wiring than Tiptap.
BlockNote (TypeCellOS) is the shortcut to a Notion-style block editor: drag-and-drop blocks, slash menu, a fully styled UI, real-time collaboration via Yjs (CRDT), and AI integration "out of the box," all on top of ProseMirror + Tiptap. The license is the catch: core is MPL-2.0 (fine for commercial/closed-source), but the "XL" packages (some advanced/AI pieces) are GPL-3.0 — read the package boundaries before shipping.
Raw ProseMirror underpins Tiptap, BlockNote, Remirror, and others. Drop to it only when you need a custom schema and total control and have the team to maintain it.
Heuristic: Tiptap by default; Lexical if scale/perf/MIT-purity dominate; Plate if you live in shadcn/ui; BlockNote if you want Notion-style with the least code (and the license fits). Avoid building on raw ProseMirror unless an editor is your product.
A second axis crosses the framework choice: headless (you control the UI, the editor controls the model — Tiptap, Lexical, Plate, ProseMirror) vs. all-in-one WYSIWYG (the vendor ships toolbar, themes, plugins, and support — CKEditor 5, TinyMCE, Froala). Nutrient's 2025 landscape piece frames the tradeoff cleanly: headless gives you design freedom and a smaller, custom surface at the cost of building UI; all-in-one gives you speed-to-feature-parity and vendor support at the cost of bundle weight, opinionated UI, and (often) commercial licensing tiers. For a custom AI-native CMS where the editor must blend into a bespoke admin, headless almost always wins — you do not want the editor's chrome fighting your design system.
"Can I see what it will look like?" is the single most common editor request. Three models dominate in 2026:
The architecturally honest path for a structured, AI-native CMS is parallel preview by default, plus optional source-mapped click-to-edit. Pure inline visual editing is seductive but tends to re-couple content to a single layout — exactly the coupling structured content exists to avoid. Implement preview by rendering your real front end against draft content (a "draft mode" / preview API key), not by re-implementing the front end inside the CMS.
Validation that fires only on save (or worse, on the API consumer) is a usability failure. An AI-native CMS should validate inline, per field, as the editor types, and surface clear, human messages. Concrete validations worth shipping:
The key UX rule: distinguish errors (block publish), warnings (allow publish, flag risk), and suggestions (purely advisory). Conflating them trains editors to ignore all three.
Inserting an image, video, or file is the action editors perform most after typing, and it is where weak editors lose them. A 2026-grade media flow includes:
Treat assets as structured references with metadata, not embedded <img> tags. That keeps content portable, makes the media AI-queryable ("find all images without alt text"), and lets you swap the delivery pipeline without touching content.
This is where authoring experience and the "AI-native" mandate meet. The field moved fast in 2025–2026, and Tiptap is the clearest bellwether.
Tiptap's first wave shipped Content AI: in-editor generation, AI Suggestion (the editor analyzes the document and shows accept/reject suggestions), autocompletion (Tab to stream a completion), and an AI Assistant. Importantly, Tiptap announced that AI Suggestion, AI Changes, and AI Assistant are being deprecated in 2026, replaced by the new AI Toolkit — "no new features" on the old extensions, maintenance only (Tiptap docs/release notes, 2025–2026). The lesson for builders: the AI-in-editor API surface is still churning; abstract it behind your own interface so a vendor's deprecation doesn't rewrite your editor.
The AI Toolkit reframes the goal as "bring Cursor-like editing to your documents": it gives an AI model the ability to read, understand, and edit the document with awareness of its content and schema, make precise edits, stream content in, and offer track-changes-style review so a human approves every AI change. Crucially, the community tiptap-apcore package exposes every editor command over the Model Context Protocol (MCP) with JSON-Schema validation and safety annotations, so any MCP-compatible agent can discover and invoke "insert," "format," "restructure" operations safely. This is the architectural pattern to internalize regardless of vendor:
Expose editor operations as a typed, schema-validated tool surface (ideally MCP), with every AI mutation routed through human-reviewable track-changes — never silent rewrites.
Concrete AI authoring features worth supporting, roughly in order of value-to-risk:
| Feature | Risk | Notes |
|---|---|---|
| Inline autocomplete (Tab) | Low | Editor stays in control; never auto-commits |
| Tone/grammar/readability suggestions | Low | Advisory marks, accept/reject |
| "Improve / shorten / expand selection" | Medium | Operate on selection, show as suggestion |
| AI-generated alt text & summaries/SEO | Medium | Always human-reviewed before publish |
| Agentic multi-step edits (AI Toolkit / agent) | Higher | Require track-changes + explicit approval |
| Full-draft generation | Highest | Useful for scaffolding; never auto-publish |
The non-negotiable design constraints: structured edits over blob rewrites (the AI edits blocks, preserving everything it wasn't asked to touch), track-changes review, provenance (mark AI-touched content for later audit), and no auto-publish of AI output without a human gate.
"Easy to use" for a non-technical editor means the interface only shows them what they can and should do. The 2025–2026 consensus role model (per DatoCMS, Contentful, Directus, Webstacks):
| Role | Can | Cannot |
|---|---|---|
| Contributor / Author | Create and edit drafts | Publish; change settings |
| Editor | Review, edit, approve, publish; manage editorial workflow | Change schema, roles, or site config |
| Publisher (optional split) | Push approved content live | Author from scratch |
| Admin / Developer | Schema, roles, integrations, config | — |
The workflow these roles drive is a small state machine — Draft → In Review → Approved → Published (plus Scheduled / Archived) — with role-gated transitions: "authors draft, editors review, publishers push live, with clear ownership meaning faster approvals and airtight accountability" (Webstacks, CMS Roles and Permissions, 2025). Beyond roles, real ease-of-use for non-technical staff comes from:
Two accessibility surfaces matter. First, the published content — the editor should help authors meet WCAG 2.2 (alt text enforcement, heading-level checks, color-contrast hints, descriptive link text warnings). Second, and often forgotten, the authoring tool itself must be operable by editors who use a keyboard or screen reader — this is the domain of W3C's ATAG 2.0 (Authoring Tool Accessibility Guidelines). Practically: every toolbar action reachable by keyboard, focus management that doesn't trap, ARIA on custom widgets, and visible focus states. Headless frameworks vary here — verify with a keyboard and a screen reader before committing; do not assume.
This is the chapter's load-bearing decision. There are three postures, from least to most effort:
| Posture | What you do | When it fits | Risk |
|---|---|---|---|
| Adopt a CMS's editor wholesale | Use Sanity Studio / Storyblok / Contentful's editor as-is | You also adopted that CMS; team is small | You inherit their UX and pace |
| Adopt a framework, build the editor UI | Tiptap/Lexical/Plate/BlockNote + your own toolbar/blocks | Custom CMS, custom design system (most readers of this report) | You own UX bugs; framework churn (e.g., Tiptap AI deprecations) |
| Build from raw ProseMirror/Slate | Custom schema and rendering | The editor is a core differentiator | High cost; you maintain a hard problem |
The strong recommendation for a custom AI-native CMS: adopt a headless framework (Tiptap by default), build the surrounding UI, and never build the rich-text engine from scratch. Rich-text editing is a notoriously deep problem — input methods (IME), collaborative cursors, paste sanitization, undo across complex selections, mobile keyboards, cross-browser contenteditable quirks. Mature frameworks have absorbed years of these bugs. Reserve raw ProseMirror/Slate for the rare case where the editor is the product.
Two caveats: (1) Avoid lock-in to a framework's paid AI cloud — wrap AI features behind your own abstraction so you can swap providers (the Tiptap AI deprecation is a live example of why). (2) Mind the licenses — BlockNote's XL packages are GPL-3.0; some Tiptap features are commercial; CKEditor/TinyMCE/Froala are commercially licensed for many uses. License posture is part of the build-vs-adopt math, not an afterthought.
A useful decision flow: Is a great editor your product's differentiator? → if yes and you have the team, consider building deeper (still on a framework). Are you on React + shadcn/ui? → Plate. Want Notion-style blocks fastest, and the license fits? → BlockNote. Need extreme scale/perf or strict MIT purity? → Lexical. Otherwise → Tiptap, build the UI around it, and spend your saved time on content modeling, AI guardrails, and preview.