Tiptap vs Lexical vs Plate: the Next.js App Router rich text editor decision (2026)

Quick answer, September 2026. All three are MIT at the core and all three shipped a stable release within the last two weeks, so "which one is still maintained" is not the question that separates them. What separates them is who holds the copyright and how much of the editor you are willing to run on the client. Tiptap is owned by one company, Tiptap GmbH, and its Pro tier is not published to the public npm registry at all. Lexical belongs to Meta and is still numbered below 1.0 after 139 stable releases. Plate is held by four named individuals and is the only one of the three that ships a dedicated server render entry point. If you are on the Next.js App Router: Plate if you need documents rendered on the server, Tiptap if you want the widest extension surface and can accept a single vendor, Lexical if you want Meta's engine and can live with an API that has never promised stability.

Every figure below was read on 13 September 2026 from the npm registry and from the published tarballs. None of it comes from another comparison post, and where we could not measure something we say so.

The three, as actually shipped

Three things in that table are worth more than the rest, and none of them is the version number.

The LICENSE files disagree about who is in charge

We pulled the licence text out of each published tarball rather than trusting the registry's one word license field, because the registry field cannot express a condition. All three say MIT. The copyright lines do not say the same thing at all.

Tiptap ships MIT License, Copyright (c) 2025, Tiptap GmbH. That is a single German company. Lexical ships MIT License, Copyright (c) Meta Platforms, Inc. and affiliates. Plate ships The MIT License (MIT), Copyright (c) Ziad Beyens, Dylan Schiemann, Joe Anderson, Felix Feng.

This is the durable axis, and it is the one worth building a decision on, because it does not move when a pricing page moves. A licence can only be changed by whoever holds the copyright. One company can relicense its own work; four individuals have to agree; a corporation the size of Meta has a process and a legal department, which cuts both ways.

Plate's licence then does something the other two do not. It carries a carve out, verbatim:

From the Plate LICENSE, as shipped: "Unless otherwise specified in a LICENSE file within an individual package directory, this license applies to all files in this repository outside of those package directories."

Read quickly, that is the standard open core move: a permissive licence at the root, with the good parts fenced off per directory. So we went and checked whether the fence is actually there. We pulled the six packages most likely to be gated, including the three that are premium features almost everywhere else in this category:

Six of six are MIT, including AI, suggestions and comments. The clause reserves a right that is not currently being exercised. That is a materially milder finding than "Plate is open core", and it is the honest one. It is still worth knowing, because the clause is the mechanism by which that could change without the root licence changing.

Tiptap runs the opposite shape. @tiptap/extension-collaboration is MIT and public, and Hocuspocus, the collaboration backend, is MIT and public too. The Pro packages are simply not on the public registry, which means they are distributed behind an authenticated registry. We are not going to put a number on what that costs, because a price is the least durable fact in any comparison and we would rather you checked it yourself. The structural fact is the one that lasts: part of Tiptap's surface is not installable without a commercial relationship, and the collaboration core is not the part that is fenced.

The rename that makes older charts wrong

If you look Plate up on a package trends chart, or read almost anything written about it before mid 2025, you will probably be looking at @udecode/plate. That package is frozen at 49.0.0, published 11 June 2025. Fifteen months of nothing.

That looks exactly like abandonment, and it is not. The registry carries an explicit deprecation notice on it:

npm deprecation field on @udecode/plate, verbatim: "Package no longer supported, use platejs instead."

The live package is platejs, first published 30 May 2025, now at 53.3.11 as of 4 September 2026. So Plate did the rename properly, signposted it in the place a package manager will actually show you, and kept shipping. The reason this matters for a comparison is that the third party charts have not all followed. The most visible npm trends comparison for this category plots lexical vs slate vs tiptap and does not include Plate under either name, so a reader doing the obvious research gets a picture with one of the three contenders missing.

Worth knowing before you read the source: platejs itself is a 126 byte file. Its entire dist/index.js is three re-export lines pointing at @platejs/core, @platejs/slate and @platejs/utils. The package is 3,644 bytes across 9 files. If you go looking for Plate's implementation in platejs you will find nothing; it lives in the scoped packages.

The App Router question, measured

Search for any of these three together with Next.js and you land on the same two questions on r/nextjs, neither of which has a good answer written for it: which editor works in the App Router, and where does the client boundary go.

So we measured it. We grepped every shipped bundle for a use client directive:

Zero across all four, and that zero is a measurement rather than a broken grep: the same pass counting the string export returned 819, 3,009, 1,104 and 15 respectively, so the files were genuinely being read.

None of these three libraries marks itself as client only. That is not a defect and we want to be careful not to dress it up as one. A library that ships use client forces a client boundary on every consumer whether they wanted one or not, and plenty of well behaved React packages deliberately decline to do that. But the practical consequence for an App Router app is real and it is the same in all three cases: you own the boundary. The editor component is yours to mark, and if you forget, the failure arrives as a server render error rather than as anything the library told you about in advance.

Only one of them can render on the server

This is where the three genuinely diverge, and it is the finding we would actually build a Next.js decision on.

Plate's package exports declare three entry points: ., ./react and ./static. That third one is not cosmetic. @platejs/core ships a real dist/static/index.js, and the symbol it exports is createStaticEditor. There is a server renderable path into the document model that does not require the React editing surface.

Tiptap's @tiptap/core declares ., ./jsx-runtime and ./jsx-dev-runtime. Lexical's core declares . and nothing else.

For a content heavy product, this is the difference that shows up in your bundle and your Core Web Vitals rather than in a feature matrix. A blog, a docs page, a knowledge base article or a marketing page usually needs to display rich text far more often than it needs to edit it. If you can render the read only view on the server, the editor bundle never reaches the reader at all. With Tiptap and Lexical the usual answer is to serialise to HTML at save time and render that string, which works perfectly well but means you are maintaining a second rendering path and keeping it in step with your schema.

We should be honest about the limit of this measurement. We read the export map and the shipped entry point; we did not build three Next.js applications and benchmark them. What we can say is that Plate ships an entry point designed for the case and the other two do not.

Module format, and one pin worth noticing

@tiptap/core and platejs both declare "type": "module". lexical declares no type field at all, which makes it a CommonJS default dual package. On modern Next.js none of this should bite you, but it is the sort of difference that surfaces in a Jest config or a transpile step rather than in a README.

One more detail from Tiptap's manifest that is easy to miss: its peer dependency on @tiptap/pm is pinned to the exact version 3.31.3, not a caret range. The ProseMirror dependencies themselves live in that @tiptap/pm package, which carries thirteen of them, while @tiptap/core has zero dependencies of its own. That is a tidy piece of architecture, and it also means core and pm move in lockstep and you cannot upgrade one without the other.

Lexical takes the opposite approach to its React binding. @lexical/react pulls in twenty dependencies, every one of them pinned to the exact same 0.50.0, and unpacks to 640 files.

Nobody here is abandoned

We checked this because it is the failure mode that actually catches people out in this category, and because we have been wrong about it before in the other direction. Days since the newest stable release, measured on 13 September 2026: Tiptap 9, Lexical 11, Plate 9. All three shipped stable inside a fortnight of each other.

The one thing worth flagging is Lexical's version number. 0.50.0, after 139 stable releases and with Meta's name on the copyright. That is not neglect, it publishes on a steady monthly-ish rhythm (0.45.0 in May, 0.46.0 in June, 0.47.0 and 0.48.0 in July, 0.49.0 in July, 0.50.0 in September). It does mean that after four and a half years the project has never taken on the semver obligation that a 1.0 implies. Read that as a statement about API stability guarantees, not about whether the code works.

How we would choose

Choose Plate if you are on the App Router and your product displays rich text more than it edits it. The ./static entry is a real architectural affordance that the other two do not offer, the whole surface including AI, comments and suggestions is MIT today, and the copyright sits with four individuals rather than one company. The costs are honest ones: it is the youngest of the three at 66 stable releases, its implementation lives one layer down in scoped packages, and the licence keeps a per directory carve out in reserve.

Choose Tiptap if you want the largest extension surface and the most polished collaboration story, and you are comfortable that part of the product sits behind a commercial registry. The zero dependency core is genuinely well factored. Go in knowing that the entity that can change the licence is one company, and check which of the extensions you are counting on are the public MIT ones before you design around them.

Choose Lexical if you want Meta's engine, you value an implementation that owns its own model rather than wrapping ProseMirror or Slate, and an API without a 1.0 stability promise is acceptable in your codebase. It is the heaviest of the three to wire up and the React binding is a large surface, but it is under the most institutionally durable copyright of the three.

What we would not do is pick on GitHub stars or on a package trends chart, because in this particular category the most visible chart is plotting a package that was deprecated fifteen months ago and omitting one of the three contenders entirely.

If you are assembling the rest of the stack around whichever you pick, the editor usually lands next to your content layer, and our headless CMS comparison covers where the document actually gets stored.

Measured 13 September 2026 against the npm registry and the published tarballs of @tiptap/core 3.31.3, lexical 0.50.0, @lexical/react 0.50.0, platejs 53.3.11 and six @platejs/* packages. Project sites: Tiptap, Lexical, Plate, and ProseMirror, the engine underneath Tiptap.