PageKit — the self-hosted GrapesJS site builder, sold as source. Get early access
Compare GrapesJS and Editor.js for structured content, visual page building, HTML/CSS editing, JSON data, components, extensibility, SaaS applications and CMS integrations.Editor.js is designed around structured content blocks. GrapesJS is designed around visual editing and page-building workflows.
If you only read one section, read this one. The two lists below are not a ranking — they are two different jobs, and most products clearly need one of them.
These tools overlap in block-based editing, but they are designed around different editor models.
Its block-based model is well suited to articles, documents and CMS content where the application stores and processes structured data. An author composes a sequence of typed blocks; the editor guarantees the shape of the data and stays deliberately silent about how it will look. That silence is the feature — the same document can be rendered by a website, a mobile app, a newsletter or a search index, each on its own terms.
Its canvas, component model, blocks, style system, assets and storage capabilities make it suitable for page builders and other visual editing products. An author arranges and styles a nested tree of components and sees the result as they work. The editor therefore needs opinions about layout, breakpoints, selectors and assets — opinions a content editor has no reason to hold.
Neither description above is a limitation. They are design decisions, and each one buys something the other gives up: Editor.js trades layout control for content that renders anywhere, and GrapesJS trades format portability for direct control of the finished page.
Both editors are libraries you mount inside your own application, and on both sides your application owns storage, authentication, permissions and the final rendering. What differs is the band in the middle: what the editor itself is responsible for, and what it hands back.
An authoring layer over a structured document.
Editor.js separates content editing from presentation and produces structured block data. Your application decides what each block type looks like when it is rendered, which is precisely why the same content can go to a web page, a mobile app, an email digest or an API response without being rewritten.
A visual editing layer over a component tree.
GrapesJS provides the visual editing layer — canvas, components, blocks, styles, assets, commands and plugins — and allows the surrounding application to control storage, publishing and business logic. What the author arranges on the canvas is what the page will look like, so the editor needs an opinion about layout that a content editor does not.
Read the ownership chips before the boxes. Neither editor is a platform: there is no hosting, no user management, no publishing pipeline and no CDN on either side. The question this diagram answers is not which library does more, but which one hands your application the kind of data your product actually needs to store.
An Editor.js document is an ordered sequence of typed blocks. There is no canvas and no layout tree, because a document does not need one — prose is linear, and a format that stays linear is a format that renders consistently everywhere it is sent.
A flat sequence is the right shape for an article. Because the structure carries no layout, one stored document can drive a web page, a native app screen, an RSS item and a plain-text digest without being converted.
Editor.js can be extended with custom Tools and blocks. A Tool controls its own markup: it builds a DOM element in render(), returns the block's data from save(), can validate that data, can define paste handling and sanitization rules, and can add its own controls to the block settings panel. Block Tunes go further and persist their own state alongside the block. Anything you can express as a block type, you can build.
@editorjs/header@editorjs/list@editorjs/image@editorjs/quote@editorjs/table@editorjs/embed@editorjs/code@editorjs/attachesWorth noting for a fair comparison: the stock Editor.js toolbox offers one block type, and the GrapesJS core ships no blocks at all. Both projects extracted their content types into packages on purpose, and neither fact is a criticism — it just means both editors are configured, not adopted. The official tool suite lives at github.com/editor-js
A GrapesJS page is a component tree, nested as deeply as the layout requires. A button lives inside a hero, which lives inside a page — and every level of that tree can be selected, restyled, reordered, duplicated or turned into a reusable block.
Nesting is what makes layout editable. Because a component knows its parent and its children, the editor can offer per-element styling, per-breakpoint overrides and reusable structures — none of which a flat sequence has anywhere to store.
The key difference is that GrapesJS treats the visual layout itself as a first-class editing experience.
If you want to see the pieces assembled from scratch rather than described, the twelve-step build is in the GrapesJS tutorial.
"Both produce JSON" is the most misleading true statement anyone can make about these two editors. Both samples below are real output, read out of a running editor rather than copied from documentation — and nothing about their shapes lines up.
await editor.save()Top-level keys
{
"time": 1788452414107,
"blocks": [
{
"id": "zRvYGn6Hw8",
"type": "header",
"data": { "text": "Build faster", "level": 2 }
},
{
"id": "bziKUc-t8d",
"type": "paragraph",
"data": { "text": "Editable copy." }
}
],
"version": "2.31.6"
}A document: a timestamp, an ordered array of typed blocks, and the editor version that wrote it. Each block carries a type and a data object whose shape is defined by its Tool. Nothing here describes layout or styling, and that is exactly what makes the format portable.
editor.getProjectData()Top-level keys
{
"dataSources": [],
"assets": [],
"styles": [
{ "selectors": ["hero"], "style": { "padding-top": "40px", "…": "…" } },
{ "selectors": ["btn"], "style": { "background-color": "rgb(75, 91, 191)", "…": "…" } }
],
"pages": [
{
"id": "SjtXdsYjpE8EJUpL",
"frames": [
{
"id": "6THykH6fmgO6bc7i",
"component": {
"type": "wrapper",
"components": [
{ "tagName": "section", "classes": ["hero"], "components": [
{ "tagName": "h2", "type": "text", "components": [
{ "type": "textnode", "content": "Build faster" }
]},
{ "type": "link", "classes": ["btn"], "attributes": { "href": "#" },
"components": [ { "type": "textnode", "content": "Get started" } ] }
]}
]
}
}
]
}
],
"symbols": []
}An editable project: pages, each with frames holding a nested component tree, plus the style rules, the assets and any symbols. This is the state you store so the author can reopen their work — not the page you serve to visitors.
GrapesJS stores project data representing the editable project structure, while HTML and CSS can be generated for publishing and export workflows. Two things surprise everyone on their first export, and both are visible below: getHtml() returns the canvas wrapped in a body element, and getCss() expands shorthand properties into longhand.
<body><section class="hero"><h2>Build faster</h2><p>Editable copy.</p><a href="#" class="btn">Get started</a></section></body>.hero{padding-top:40px;padding-right:40px;padding-bottom:40px;padding-left:40px;text-align:center;}
.hero h2{margin-bottom:8px;font-size:28px;}
.btn{display:inline-block;border-top-left-radius:8px;background-color:rgb(75, 91, 191);color:rgb(255, 255, 255);}Measured output from the same canvas that produced the project data above. Pass avoidProtected to drop the editor's own canvas reset, which is editor chrome rather than part of your page.
There is no shared subset. An Editor.js block says "level 2 heading with this text"; a GrapesJS component says "an h2 element with these classes, inside this section, styled by these rules". Going one way you must invent the markup and layout that were never stored; going the other you must discard them.
If you are migrating from Editor.js, you should treat this as a content-model and editor-model migration rather than a simple JSON conversion.
See what a migration involvesEvery cell below names a mechanism, not a score. There is no tick-and-cross column, because a cross against Editor.js for responsive layout editing would be false — a custom Tool can do it — and a tick would be misleading. "Custom" is the honest answer, and it is the one an engineer estimating work actually wants.
How to read this table
Rich text editing
Editor.js
Built-inGrapesJS
Built-inEditor.js has an inline toolbar in the core; GrapesJS has a built-in rich text editor that can be replaced with CKEditor, TinyMCE, Froala or Quill via a plugin.
Block-based content
Editor.js
Built-inGrapesJS
Built-inBoth are block-based. Editor.js blocks are content types in a sequence; GrapesJS blocks are draggable presets that insert components into a tree.
Structured JSON output
Editor.js
Built-inGrapesJS
Built-inEditor.js returns a document; GrapesJS returns project data. Both are plain JSON, and they describe different things.
Visual canvas
Editor.js
CustomGrapesJS
Built-inEditor.js edits the content area in place; there is no separate canvas surface with device widths and per-element selection.
Drag-and-drop
Editor.js
PackagesGrapesJS
Built-inEditor.js core moves blocks with move-up/move-down tunes and a blocks.move() API; pointer dragging is a community plugin. GrapesJS drags components onto a canvas.
HTML/CSS editing
Editor.js
CustomGrapesJS
Built-inGrapesJS edits selectors and declarations directly and exports HTML and CSS. In Editor.js this would be a Tool you write.
Responsive layout editing
Editor.js
CustomGrapesJS
Built-inGrapesJS ships device widths and per-breakpoint style overrides. An Editor.js Tool can hold responsive data, but you define both the UI and the semantics.
Custom blocks
Editor.js
Built-inGrapesJS
Built-inBoth are genuinely extensible. Editor.js custom Tools own their markup, data and settings panel; GrapesJS custom component types own their model, view and traits.
Component model
Editor.js
Built-inGrapesJS
Built-inEditor.js models a sequence of Tools; GrapesJS models a nested component tree with parents, children and traits.
Style manager
Editor.js
CustomGrapesJS
Built-inGrapesJS has a Style Manager bound to the selection and the active breakpoint. Styling in Editor.js is whatever your renderer decides.
Asset management
Editor.js
Your appGrapesJS
Built-inGrapesJS has an Asset Manager; uploads are still your endpoint. Editor.js image handling is an official Tool pointed at your upload endpoint.
Reusable layouts
Editor.js
CustomGrapesJS
Built-inGrapesJS has symbols and blocks for reuse. Reusable content in Editor.js is generally handled above the editor, in the application.
Multi-page projects
Editor.js
CustomGrapesJS
Built-inGrapesJS project data holds an array of pages. Editor.js is one document per instance; multiple documents are your application's model.
Storage
Editor.js
Your appGrapesJS
Built-inGrapesJS has a Storage Manager with a remote adapter you point at your API. Editor.js gives you save() and you persist the result. Either way the database is yours.
Publishing workflow
Editor.js
Your appGrapesJS
IntegrationNeither publishes anything. GrapesJS exports HTML and CSS you hand to your pipeline; Editor.js hands you JSON your renderer consumes.
Read-only mode
Editor.js
Built-inGrapesJS
Built-inEditor.js has had a read-only mode since 2.19. GrapesJS can lock components and disable editing.
Editor UI translation
Editor.js
Built-inGrapesJS
Built-inBoth can translate their own interface. Editor.js has an i18n API; GrapesJS has a locale/messages configuration.
SaaS page builder
Editor.js
CustomGrapesJS
Strong fitGrapesJS is widely used as the editor inside page-builder products. Building the same product on a content editor means writing the layout editor yourself.
Embeddable visual editor
Editor.js
CustomGrapesJS
Strong fitGrapesJS mounts into a DOM element and is commonly embedded in other people's products. Editor.js embeds just as easily, but embeds a content editor.
White-label editor
Editor.js
CustomGrapesJS
Strong fitGrapesJS panels, icons and CSS can be replaced wholesale. Editor.js UI can also be restyled; there is less chrome to rebrand.
CMS integration
Editor.js
Built-inGrapesJS
Built-inBoth integrate with a CMS. The question is whether the CMS stores structured content or a visual layout.
TypeScript types
Editor.js
Built-inGrapesJS
Built-inBoth ship type declarations in the published package. See the table below for the exact fields.
Plugin ecosystem
Editor.js
PackagesGrapesJS
PackagesEditor.js has official tool packages plus a community ecosystem; GrapesJS has a plugin API and a marketplace.
Open-source licence
Editor.js
Built-inGrapesJS
Built-inEditor.js is Apache-2.0. The GrapesJS core is BSD-3-Clause. Both permit commercial and closed-source use.
Rows where both columns read the same are rows where the two editors genuinely do the same thing. If you are scanning for a decision, the rows that matter are the ones where one side says "built-in" and the other says "custom": that gap is the work your team would be taking on.
| Package | Version | Licence | Type declarations |
|---|---|---|---|
| @editorjs/editorjs | 2.31.6 | Apache-2.0 | types/index.d.ts |
| grapesjs | 0.23.6 | BSD-3-Clause | dist/index.d.ts |
Read from the npm registry on 2026-09-03. Versions move; the licences and the shipped type declarations are the durable facts here. Note that BSD-3-Clause applies to the GrapesJS core — the separate React wrapper package is MIT.
Fourteen concrete products, each with one recommendation. Four of them point at Editor.js and two point at both — if a comparison page pointed every scenario at its own product, you would be right not to trust it.
Authors write prose. The value is in clean structured content that renders identically in every channel, not in per-post layout control.
Documentation wants a consistent template and constrained block types. Letting each page author its own layout is usually a problem, not a feature.
Search, versioning and reuse all get easier when articles are structured data rather than markup.
If your API serves content to several front ends, storing a portable document beats storing one channel's layout.
Marketing pages exist to look specific. Layout, spacing and breakpoints are the work, and they need to be editable without a deploy.
Read the guideMultiple pages, shared headers and footers, per-page layout — a component tree with a pages array is the shape of the problem.
Read the guideYour users are building the artefact they are paying for. They need to see it while they build it.
Read the guidePanels, icons and styling can be replaced so the editor reads as part of your product rather than a guest inside it.
Read the guideMounts into a DOM element inside someone else's application, with storage and publishing wired to their backend.
Read the guideSelectors, declarations and exportable markup are the deliverable. A content editor deliberately hides all three.
Read the guideWhen editors need to control the final layout rather than author fields, the CMS needs a visual editing layer.
Read the guideEmail templates are layout under hostile constraints — tables, inline styles, client quirks — which is layout editing, not content editing.
Read the guideVisual editing for the pages, structured content for the posts. Two authoring surfaces, two editors, one application.
See how to layer themConstrained structured content for the docs themselves, visual editing for the marketing pages around them.
For mixed scenarios, both can be appropriate depending on whether the primary requirement is structured content or visual layout editing. It is worth deciding which of the two your product's core loop actually is before you decide which editor to install.
Are your users primarily writing content, or visually building the thing they are creating?
That one question decides more than any feature table. Compare the two workflows your users would actually repeat, dozens of times a week, and pick the editor whose loop matches it.
Editor.js loop
GrapesJS loop
For SaaS products where users need to visually construct pages, templates or layouts, GrapesJS is often a more natural starting point — the loop above is the product, and building it on a content editor means writing the layout editor yourself. If your users are writing rather than composing, the shorter loop is the right one and Editor.js gets you there faster.
There are two honest ways to build a CMS editor, and the choice is upstream of the editor you install. Both models below are in production somewhere, and both are correct for the products that chose them.
Structured CMS
Visual CMS
The choice depends on whether your users need to author structured content or visually control the final layout. If some need each, that is a real answer too — see the section on running both further down.
The easiest way to understand the difference is to use the editor. Drag a block in from the panel, click any element, restyle it, switch the canvas to tablet or mobile, open the asset manager — and watch the panel below print where your selection sits in the component tree.
Yes, but migration is usually a content-model and editor-architecture migration rather than a direct export/import operation. There is no converter that reads an Editor.js document and produces a GrapesJS project, because the layout and markup a visual editor needs were never in the document to begin with. Someone has to decide them, once per content type — and that decision is what the ten steps below organize.
Audit your Tools
List every Tool in use, including the ones only a handful of old documents rely on. The long tail is where migrations overrun.
Identify content types
Group those Tools into the content types your product actually has. Several Tools often turn out to be one type with variations.
Map block data
For each type, write down what its data object holds and what a visual equivalent would need that the data does not contain.
Create GrapesJS components
Define a component type per content type, with the markup and structure the visual editor will render and edit.
Create traits and properties
Expose the fields authors need to edit as traits, so the settings panel offers the same controls the old Tool did.
Create visual blocks
Add a draggable block per component type so authors can insert them, which is the visual counterpart of the Editor.js toolbox.
Map styles and layout
Decide which styling is fixed in the component and which the author may change, then configure the Style Manager to match.
Migrate templates and content
Convert stored documents with a script per content type. Expect to hand-check a sample — automated output will need judgement.
Rework the frontend
Your renderer consumed a blocks array. It now consumes exported HTML and CSS, or project data, which is a different integration.
Verify rendering
Compare old and new output for real documents, not fixtures, and keep the old pipeline readable until you have.
One heading, both ways. The comparison below is deliberately small, because the gap it shows is the whole difficulty of a migration: everything on the right that is not on the left had to be decided by a person.
{
"type": "header",
"data": {
"text": "Build faster",
"level": 2
}
}Semantic and portable. It says what the content is — a level 2 heading — and nothing about how it should look.
{
type: 'text',
tagName: 'h2',
components: [{ type: 'textnode', content: 'Build faster' }],
}A component definition: what Blocks.add() and Components.addType() take. Note what appeared out of nowhere — the tag, the structure, the text node. None of it was in the block.
Editor.js concept
GrapesJS concept
Each Tool becomes a component type: same idea, but the component owns a model and a view rather than a DOM element and a save() method.
Fields the Tool held in its data object become component properties, with traits for the ones an author should be able to change.
A flat, ordered array becomes a nested tree. This is the step with no mechanical answer — nesting has to be designed.
Your stored document schema becomes project data plus whatever your application still needs to model around it.
This is a conceptual mapping, not a universal automatic converter. Not all Editor.js Tools can be reused, and not all Editor.js content can be converted automatically — the mapping above is what a person applies per content type, and its difficulty depends entirely on how much layout intent was implicit in your old renderer.
It depends on inputs we cannot see from here, so the three tiers below describe those inputs rather than promising a duration. The same three Tools take an afternoon in an application that renders JSON in one component, and considerably longer in one with server-side rendering, a template library and an editorial workflow.
Stock tooling, little custom code, and a renderer you can rewrite in an afternoon.
Custom Tools and templates exist, so each one needs a designed visual equivalent.
The editor is deeply woven into rendering, workflow and other systems.
Before migrating production content, audit the current Editor.js data model and rendering pipeline.
A fair share of people who search for an Editor.js alternative do not need one. Three outcomes are worth considering before a migration, and only one of them is a migration.
If your product stores and renders structured content, and the complaints you hear are about block types rather than layout, the editor is not the problem. Replacing it would cost you the portability you are currently getting for free.
When structured content is exactly what your product needs
Custom Tools own their own markup, data and settings panel, and Block Tunes can persist state per block. A surprising number of "we need a different editor" requirements are one Tool away.
When you only need additional content Tools
If the requirement is genuinely a visual layout editor — landing pages, templates, a builder your customers use — then adding one is the honest answer, and it does not have to mean removing the content editor you already have.
When the product needs a visual layout editor as well
In some applications, Editor.js can remain the content authoring tool while GrapesJS handles visual composition. The two editors do not talk to each other — they each serve a different authoring surface of the same product, as the diagram shows.
Your application
Structured content
Posts, docs and any content that has to render in more than one place.
Visual layout
Landing pages, templates and anything where the layout is the deliverable.
You don't have to build every editor capability from scratch. GrapesJS can be extended with plugins for common workflows and integrations — including, for anyone arriving from a content editor, the rich text experience itself.
The question everyone arriving from a content editor asks first: does the writing experience survive inside a visual canvas? GrapesJS has its own rich text editor, and it can be swapped for the one your authors already know.
Browse the categoryReplaces the built-in rich text editor with CKEditor 5, editing inline on the canvas.
TinyMCE 6 as the inline text editor, for teams whose authors already use it.
Froala as the canvas rich text editor, with its own toolbar and plugins.
Quill as the rich text editor — a lighter option with no licence to negotiate.
The GrapesJS core ships no blocks, which is why block packs are the most common first install. These are the draggable presets your authors insert.
Browse the categoryThe baseline set: sections, columns, text, images and links to start from.
Tailwind-classed blocks, for products whose design system is already Tailwind.
Bootstrap 5 blocks and components, mapped to the framework's own markup.
Document-oriented blocks — closer to article layout than to landing pages.
Component types add editable structures with their own traits — the visual counterpart of writing a custom Editor.js Tool, except someone else already wrote it.
Browse the categoryA set of editable component types with traits, ready to drop into the block panel.
A tabbed component with its own panel structure and traits.
Form components — inputs, selects, checkboxes and the form element itself.
Project data has to go somewhere. Storage plugins wire the Storage Manager to a backend so you are not writing a persistence adapter on day one.
Browse the categoryPersists project data through Directus, so the CMS remains the source of truth.
Storage adapter for Firebase, useful when the app is already there.
Local persistence in the browser — handy for drafts and for demos.
Adds multi-page management on top of the project data pages array.
Beyond the four above, the catalogue carries further inline-editor integrations and extensions to the built-in one.
If your product already has a design system, blocks that emit its classes matter more than blocks that look nice.
Asset pickers and deployment commands, for the parts of the pipeline that sit either side of the editor.
Two listings genuinely do AI work rather than name it. They are linked directly because the AI category hub has no published products behind it.
Listings and prices are read from the marketplace at build time; the slug lists behind these shelves were last checked on 2026-09-03. A listing that has since been withdrawn simply disappears from its shelf.
Six products that are all the same editor configured differently. Each has its own guide, because the interesting decisions are in the configuration rather than the install.
A page builder your customers use inside your product, with their pages stored in your database.
Read the guideAn editor that mounts inside another application, wired to that application's storage and publishing.
Read the guideMarketing pages your team can compose and restyle without waiting for a deploy.
Read the guideThe same engine with your panels, icons and styling, so it reads as part of your product.
Read the guideA visual editing layer over a headless backend, for editors who need to control the final layout.
Read the guideEmail templates under the constraints email actually imposes — tables, inline styles and client quirks.
Read the guideThe editor mounts into a DOM element, so the framework question is about how you wrap it rather than whether it works. Each guide below covers the wiring, the lifecycle and the parts that surprise people.
The official React wrapper, its required props, and where React's lifecycle collides with the editor's.
GrapesJS with ReactDynamic import, server-side rendering constraints and where the editor may and may not be mounted.
Next.js page builderMounting into a template ref, and why there is no official Vue wrapper to reach for.
GrapesJS with VueComponent lifecycle, zone handling and cleaning up the editor on destroy.
GrapesJS with AngularThe shipped type declarations, what they do and do not export, and the minimum compiler version.
GrapesJS with TypeScriptNo framework at all: a script tag, a container element and an init call. Start here to see the core clearly.
GrapesJS tutorialOne clarification worth making explicitly: the GrapesJS core is framework-agnostic and can be integrated into applications using these frameworks — it does not use the same component model as React or Vue. A "component" in GrapesJS is the editor's own model object describing a node in the canvas tree, not a React or Vue component, and the canvas renders real DOM inside an iframe rather than a framework's virtual tree. Wrappers integrate the editor into your app; they do not put your framework's components inside the canvas.
Twenty requirements, one recommended starting point each. Six point at Editor.js and two at both, because that is where they actually point.
| Your requirement | Recommended starting point |
|---|---|
| Blog editor | Editor.js |
| Article editor | Editor.js |
| Documentation | Editor.js |
| Structured content | Editor.js |
| JSON-first content workflow | Editor.js |
| One document, many channels | Editor.js |
| Visual page builder | GrapesJS |
| Landing page builder | GrapesJS |
| SaaS page builder | GrapesJS |
| HTML/CSS editor | GrapesJS |
| White-label visual editor | GrapesJS |
| Embeddable visual editor | GrapesJS |
| Visual CMS editor | GrapesJS |
| Custom page composition | GrapesJS |
| Responsive layout control | GrapesJS |
| Reusable visual templates | GrapesJS |
| Email template editing | GrapesJS |
| Multi-page projects | GrapesJS |
| Marketing site with a blog | Either, or both |
| Docs plus marketing pages | Either, or both |
Neither tool is universally better. Choose based on the editing model your product requires.
If the audit points at a migration, GJS.Market can help with the parts that are specific to this pair of editors rather than generic to any rewrite.
We scope from your actual data model and rendering pipeline, so the first conversation is about what you have rather than what we offer. We do not quote a duration before that audit, because the honest answer depends on the eight factors listed above.
Editor.js is a strong choice for structured content editing. GrapesJS is a strong choice when users need to visually build and customize pages, layouts and components.
Twelve steps from an empty container to a configured editor with blocks, styles, storage and exports.
Open the tutorialRich text integrations, block packs, component sets and storage adapters, so you configure rather than build.
Browse the marketplaceArchitecture assessment, content model mapping and migration work scoped from your actual data model.
Talk to usIf your product needs visual editing, start with GrapesJS and extend it around your application's architecture. If it needs structured content, the shorter answer is the right one — and this page has hopefully made it obvious which of those you are reading about.
-thumbnail.jpg&w=3840&q=70)