What Slate is, and what it is not
Slate is an open source framework for building rich text editors in React. It is not a finished editor. You get a document model, a selection model and a plugin system, and you build the toolbar, the formatting rules and the block types yourself. That control is the reason teams pick it.
The caveat is on the first page of the README. As of October 2026 Slate still says it is in beta, that some APIs are not final and may break, and that there is no 1.0 schedule. The repository is MIT licensed and widely used, but you should pin versions and budget time for upgrades.
Slate, Lexical, TipTap or Plate
| Option | Built on | Pick it when |
|---|---|---|
| Slate | Its own tree model, React | You need unusual blocks, embedded widgets, or a data model close to your own JSON |
| Plate | Slate | You want Slate with ready plugins and shadcn-style components, and less custom work |
| Lexical | Meta’s framework, not React-only | You want a smaller core, framework flexibility and Yjs collaboration out of the box |
| TipTap | ProseMirror | You want a mature schema, many extensions and a hosted collaboration option |
| ProseMirror | Itself | You need strict schemas and full control, and accept a steeper learning curve |
Our rule of thumb: if a standard editor is enough, take TipTap or Plate and ship in weeks. Take Slate itself when your content has structure that those editors fight against, such as nested layout blocks, inline data references or domain-specific nodes. Take Lexical when the team wants Meta’s direction and built-in collaboration support. Several CMSs made this choice for you: Payload’s editor moved to Lexical, and Strapi’s Blocks editor is built on Slate.
Serialising content
The editor state in Slate is a JSON tree. Keep that tree as the source of truth and convert at the edges:
- Portable JSON: Store the tree as it is, with a version field for the schema. This round-trips perfectly and is what we recommend.
- HTML: Render on the server from the tree for public pages. Do not store HTML as your master copy, because getting back from HTML to the editor loses information.
- Markdown: Fine for docs and import or export. Plan for nodes Markdown cannot express, and decide up front what happens to them.
Write the serialisers as pure functions with tests, one per node type. Most production bugs we see are in paste handling and in content saved under an old schema.
Collaboration
Slate’s own site notes that its data model is built so collaboration can be layered on later. In practice teams use Yjs bindings for real-time editing, or keep it simple with locking and autosave. Real-time editing adds a sync server, presence, and conflict rules for your custom nodes, so decide whether you need it before you choose the editor.
Storing editor content in a headless CMS
Most teams do not build a CMS around the editor. They use a headless CMS for storage, roles and delivery, and embed a custom editor as a field type. Strapi supports custom fields and plugins, Sanity lets you replace its input components, and Payload lets you extend its rich text field. The editor stores the JSON tree, the CMS validates and versions it, and the front end renders it. Our guide on what a headless CMS is explains the split.
What we build
We build Slate editors in React with TypeScript types for every node and mark, so invalid documents fail at compile time instead of in production. Typical work: custom blocks and inline elements, slash menus and toolbars, paste cleanup from Word and Google Docs, mentions, comments, HTML and Markdown serialisers, schema migrations, and performance fixes for long documents. If a different editor fits better, we say so before we start.
