# The visual editor library ecosystem in 2026: what our dataset tells us

*Source: https://www.editorstack.cc/research/editor-library-ecosystem-report — last updated 2026-09-17. Licensed CC BY 4.0 with attribution to EditorStack.*

## Summary

- The EditorStack dataset covers products in four groups that do genuinely different jobs: embeddable libraries, commercial SDKs, headless CMSs with visual editing, and hosted platforms that cannot be embedded at all.
- Just over half of the products can be run entirely on infrastructure the buyer controls, and a slightly larger share can be shipped to a buyer's own customers under the buyer's brand — the two constraints that eliminate most shortlists before features are discussed.
- In the email category, entry prices differ by a factor of six while capabilities barely differ; what differs is the meter, and metering mismatch explains more regretted purchases than any missing feature.

## What this report is

This is an analysis of our own dataset rather than a survey of opinions. Every figure below is
computed from the 34 product records published at [/api/libraries.json](/api/libraries.json), and you
can recompute any of them yourself.

The point is not to rank products. It is to describe the shape of the category, because the shape
explains most of the confusion buyers experience.

## The category is four categories

Products marketed with the same words do four different jobs:

**Embeddable libraries (13).** You install them from npm and mount them in your
application. Your data, your hosting, your interface work. GrapesJS, Puck, Craft.js, Editor.js,
Plate, Tiptap, Lexical, React Page, Silex, CKEditor 5, TinyMCE, BlockNote and Quill.

**Commercial SDKs (9).** Licence-key products supplying a finished editor plus
infrastructure. Builder.io, Plasmic, TeleportHQ, Unlayer, Beefree SDK, Stripo, Topol, the GrapesJS
Studio SDK and PageKit occupy this space with very different shapes.

**Headless CMSs with visual editing (4).** Storyblok, Sanity, Contentful Studio and
Directus. Their editors serve your content team, not your customers.

**Hosted platforms (8).** Webflow, Framer, Elementor, Wix Studio, Duda, Brizy,
Sitejet and Zillapage. Mostly not embeddable at any price; present because every build-versus-buy
conversation compares against them.

The single most common evaluation error we see is comparing across these groups on features. A CMS
and an embeddable library can both be described as "visual editing" and neither can do the other's
job.

## The two constraints that decide most shortlists

**Self-hosting.** 18 of 34 can run entirely on infrastructure the buyer
controls. If page content cannot leave your network, nearly half the category is gone before features are
discussed.

**Resale under your own brand.** 20 of 34 can be shipped to your own customers as your product. The
best-known names — Webflow, Framer, Builder.io, Plasmic — are not among them, which is why the search
for a "white-label website builder" is so frustrating and why the
[white-label category page](/categories/white-label-website-builders) exists.

Answer these two questions first and the shortlist usually resolves to three or four candidates.

## Pricing has stopped being about price

The email sub-category illustrates this most sharply. Four products with materially similar
capabilities charge:

- around $60 per month, metered by customer accounts that open the editor;
- $100 per month, metered by unique templates created;
- $250 per month, a flat platform tier;
- $350 per month, a platform tier plus usage components.

A product with 2,000 light accounts and a product with 40 heavy accounts will find these four in
completely different orders. The capability differences between them are small; the metering
differences are decisive.

This generalises beyond email. Builder.io moved to credit-based pricing that meters work done rather
than seats occupied. Storyblok meters spaces, which punishes agencies. Directus meters your company's
revenue. Framer and Webflow charge for seats separately from plans.

The practical conclusion: model the meter against your own shape before comparing headline prices. Our
[build-versus-buy calculator](/use-cases/build-vs-buy-visual-editor) does the licence-versus-hours
half of this; the meter half needs your own numbers.

## What every product in the dataset refuses to do

Three capability gaps recur across the whole category, and they are worth knowing because they will
not be filled by choosing differently.

**Nothing server-renders.** Every editor here mounts against a live DOM. Editing is always a
client-side, authenticated concern, and any architecture that assumed otherwise needs revising.

**Nothing gives you both React-native components and portable HTML output.** Component-tree editors
store data that means something only inside your app; HTML editors cannot render your React components
in the canvas. Teams that need both — a page builder and an email builder, say — run two editors,
and that is the correct answer rather than a compromise.

**Nothing includes the surrounding product.** Asset management, permissions, versioning and publishing
are yours in every open-source option and vary widely in the commercial ones. Our model puts that work
at roughly 480 hours, and it is the single most underestimated line in editor projects.

## Measurement findings

We measured what we could rather than what would make a better chart.

**Bundle sizes span 13.5×**, from Craft.js at 29.2 kB gzip to TinyMCE at 393.9 kB, and the
spread tracks how much editor interface each library includes rather than how capable it is. See the
[bundle benchmark](/research/bundle-size-benchmark-2026).

**Time to a rendered editor spans 14.3×**, from 70 ms to 1004 ms, and again the ordering
tracks how much appears on screen. See the
[time to first editor benchmark](/research/time-to-first-editor-benchmark).

**Only 12 of 34 products could be measured at all.** The rest are hosted services behind
licence keys or platforms with no local build. That is the clearest structural fact about this
category: most of it cannot be independently benchmarked by anyone, which is precisely why vendor
claims dominate the conversation.

## What we cannot tell you

This report analyses products, not usage. We do not know which of these is most deployed, how
satisfied their users are, or how often teams abandon an editor project — because nobody has published
that data and we have not collected it.

That is why the [State of Visual Builders survey](/research/state-of-visual-builders-2026) exists as
an open survey rather than as a page of numbers. When it has enough responses to be worth reporting,
the results will appear there with the sample size attached.

## How to cite this

> EditorStack (2026). *The visual editor library ecosystem in 2026*. Computed from the EditorStack
> dataset, 19 August 2026. https://www.editorstack.cc/research/editor-library-ecosystem-report

The dataset is [CC BY 4.0](/data). See [how to cite](/cite) for BibTeX.


## Frequently asked questions

### How many visual editor libraries are there?

Our dataset covers the products teams actually shortlist, with the current count on this page: embeddable libraries you install from npm, commercial SDKs behind licence keys, headless CMSs whose visual editing serves your own content team, and hosted platforms included as build-versus-buy reference points.

### How many can be self-hosted?

Just over half of the products in our dataset can run entirely on infrastructure the buyer controls; the exact count is computed on this page. That constraint alone removes several of the best-known products from a regulated buyer's shortlist.

### Are open-source editors cheaper overall?

Only if you value engineering time at zero. Our model puts a customer-facing editor on an open-source engine at roughly 520 hours, which at a blended $85 per hour exceeds two years of most commercial SDK subscriptions.


## Sources

1. [The dataset this analysis is computed from](https://www.editorstack.cc/api/libraries.json) — accessed 2026-08-19