Tiptap and the paid layer sitting on top of an MIT editor

Headless means the interface is your project, not theirs

The editor ships without a user interface, and the README is direct about why: it means full design freedom, and no need for class overrides or code hacks. The same passage says the editor is designed to work across frontend frameworks, naming Vue, React, and plain JavaScript as equally supported, which is the framework-agnostic claim in its plainest form.

So adopting Tiptap means adopting two projects: the editor engine, and the toolbar, menus, and empty states you have to build on top of it. The proof is in what the project publishes instead of a component library. There is a React notion-like block editor template at templates.tiptap.dev, a basic editor CodeSandbox, a collaboration-ready CodeSandbox, and a root serve script that builds the demos and exposes them over http-server on port 3000. The demos are the reference implementation. The cost of headless is simply that the visible half of the work does not arrive with the package.

The paid tier is named in the README, feature by feature

The licensing split is not subtle. LICENSE.md is the MIT License, and the root package.json is private, which is normal for a monorepo that publishes its packages rather than itself. Above that sit the Pro Extensions, described as additional features that integrate into the base editor, and they need a valid subscription. The named list is collaborative editing, commenting, versioning, document conversion, and AI related features.

The About section states the arrangement plainly: Tiptap is a collection of developer components based on open source technology, forming the basis of the advanced, paid features, and it names the open source editor component, collaboration features, Content AI, and Tiptap Cloud. For an evaluator the practical reading is that MIT covers the core editor packages and the money covers the list above it. The one ambiguity the repository does not resolve is collaboration, which appears both as the open source Hocuspocus backend and as a Pro feature. Settle that boundary in writing before your architecture depends on it.

Collaboration is a second service built on Yjs, not a flag

Hocuspocus is described as a collaboration backend built around the CRDT power of Yjs, and the editor plus Hocuspocus together form what the project calls the Tiptap Suite, with Hocuspocus serving as its backbone. A collaboration-ready CodeSandbox exists so you can see the wiring, and the examples index collects the rest.

What this means operationally is that collaborative editing is not a setting inside the editor. It is a service you deploy, connect to, and keep running, and this repository does not document how to scale it, authenticate clients against it, or persist its documents. The README hands you the CRDT choice and the sandbox; the deployment questions are left to the documentation and the community. A reader who only needs a single-user rich text field should skip the whole second service, and a reader who needs multi-user editing should price the hosting as a line item rather than assume the editor covers it.

Three patch releases in two days, and a changelog to read them in

The recent tag dates are worth reading closely: v3.31.1 and v3.31.2 both landed on 2026-09-03, v3.31.3 followed on 2026-09-04, and the last push to main is dated 2026-09-29. This is a project under active development, which is exactly what you want in a dependency that ends up inside your product.

The same fact cuts the other way. Three patch numbers in forty-eight hours means patch-level churn, and a floating version in your package.json hands that decision to whoever published last. The tag dates alone tell you nothing about what changed, so the diff you actually need lives in CHANGELOG.md at the repository root, and reading it is part of upgrading rather than an optional courtesy. If you pin, you get stability and the obligation to track those notes yourself. If you float, the lockfile is the only record of what you tested.

Releases run through changesets with npm publish provenance

The publishing setup is unusually explicit for a library. The root manifest is private with publishConfig.provenance true, and the release path is short:

"test": "vp run -r build && vp run test:unit",
"test:e2e:all": "playwright test",
"publish": "vp run build && vp exec changeset publish"

A .changeset/ directory at the root holds the pending version notes, a check:package-exports script runs node scripts/check-package-exports.mjs against the workspace, and a clean:packs script removes the ./packages/*.tgz files, which tells you the packages are built as tarballs before they go out. Provenance means the publish is attested rather than anonymous, and the exports check means a package cannot quietly ship a broken entry point. What it does not mean is that the @tiptap/... packages move in lockstep, so a mixed-version node_modules is a state your own tests have to rule out.

Half the contribution rules are machine readable files

The tree carries the usual human files, CONTRIBUTING.md, SECURITY.md, CHANGELOG.md, and commitlint.config.mjs, and then a set that exists to be read by tools: AGENTS.md, CLAUDE.md, a .codex/ directory, a skills/ directory, .coderabbit.yaml, .zed/, .vscode/, and .vite-hooks/. There is also a .fallowrc.json with fallow audit and fallow health --score --targets scripts.

The consequence for a contributor is that the documented rules and the enforced rules are not the same document. A human reading CONTRIBUTING.md sees a subset of what the hooks and agent instructions apply, and a pull request can be shaped by configuration the README never mentions. The health script with a score target suggests the project tracks some internal measure of repository health, and nothing in the README explains what that score covers or what happens when it drops. Read the config files in the tree alongside the contributing guide rather than instead of it.

The sponsor list is a map of who benefits from the paid tier

The funding section is unusually concrete. Seven companies appear as sponsors with logos and links: Complish, Storyblok, PostHog, Reflect, Ziff Media, Basewell, and Poggio. A second line adds iFixit, ApostropheCMS, Novadiscovery, Omics Data Automation, Flow Mobile, DocIQ, and then hundreds of individuals through GitHub Sponsors.

Every one of those names is a company shipping software on top of an editor, and several are paid products themselves. That is a governance fact rather than a defect, but it is worth pairing with the Pro extension list: the constituency for roadmap decisions includes businesses with a direct interest in features that could reasonably be sold, which is the same tension the About section describes when it says the open source products also shape the paid features. Support runs through GitHub Discussions, chosen deliberately for being searchable, and the project is tracked by the Linux Foundation insights page as well.

Editorial conclusion

Tiptap fits a team that wants to own its own editor interface and can live inside the ProseMirror model, and it fits anyone willing to run Hocuspocus for collaboration. It is a poor fit if you need a ready-made UI, if collaborative editing has to stay entirely in the free tier, or if a subscription decision has to be made before the design is. Before you commit, price the Pro extension list, run the open collaboration backend yourself if you can, and read CHANGELOG.md at the tag you pin, since three patch releases landed on 2026-09-03 and 2026-09-04 alone.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes