PageKit — the self-hosted GrapesJS site builder, sold as source. Get early access
Compare GrapesJS and Unlayer for email and page building, customization, hosting, storage, integrations, pricing, and developer control. Find out which visual editor is the better foundation for your product.
A managed editing platform. Your app loads the SDK, and the editor plus the features around it are operated by Unlayer. The design JSON comes back to you.
An editor framework you install. Your app owns the components, the API it saves to, the database behind it and the pipeline that publishes the result.
Most of this page is detail. The choice underneath it is short, so here it is before anything else. Neither answer is wrong — they solve different problems.
Unlayer ships four builders — email, page, popup and document — behind one SDK, and runs the editor for you. If the platform already does what your product needs, adopting it is less work than building the equivalent.
GrapesJS is an editor framework you install and extend. Nothing about the canvas, the block set, the panels or the storage is decided for you — which is the point when visual editing is a feature of your product rather than a tool beside it.
Both products put a drag-and-drop canvas in front of your users. The difference is everything around that canvas: who runs the editor, who decides how it behaves, and how much of the surrounding product is yours to define.
A managed editing platform. Your app loads the SDK, and the editor plus the features around it are operated by Unlayer. The design JSON comes back to you.
An editor framework you install. Your app owns the components, the API it saves to, the database behind it and the pipeline that publishes the result.
With Unlayer, less of the diagram is yours to build — and less of it is yours to keep running. That is the trade, stated in its favour.
With GrapesJS, more of the diagram is yours. Every box you own is a box you decide, and a box your team maintains.
GrapesJS gives you the visual editing engine. Your application decides how the rest of the product works.
Unlayer
GrapesJS
Unlayer builders
Four builders behind one SDK, selected with the displayMode option. Unlayer is not an email-only product.
Unlayer framework components
Official components for all three major frameworks. GrapesJS publishes an official React wrapper only; Vue and Angular use the plain JavaScript API.
Most rows below are not yes-or-no answers, so they are not written as ✓ and ✗. "Native", "via plugin", "plan dependent" and "your application" are the honest answers, and a table that flattened them into ticks would be easier to read and wrong.
| Capability | GrapesJS | Unlayer |
|---|---|---|
| Product type | Open-source editor framework you install | Managed embeddable editing platform |
| Email builder | Via presets and plugins (MJML, newsletter block sets) | Native — the email display mode |
| Page builder | Native — the default canvas | Native — the web display mode |
| Popup / document builder | Custom implementation on the same canvas | Native — the popup and document display modes |
| Visual editing | Native | Native |
| Drag & drop | Native | Native |
| Custom blocks | Native — BlockManager, unlimited, defined in your code | Plan dependent — Custom Blocks from the Scale tier |
| Custom components | Native — your own component types, models and traits | Custom Tools — from the Launch tier |
| Templates | Your application — JSON you define and store | Your application, plus hosted template features by plan |
| Assets | Asset Manager wired to your storage | Hosted by default; Custom Storage from the Launch tier |
| Responsive editing | Native — Device Manager, your own breakpoints | Native; mobile design mode from the Launch tier |
| Custom editor UI | Native — panels, commands and layout are your code | Plan dependent — custom CSS, themes and tabs from Optimize |
| White-label | Native — the editor ships inside your bundle | From the Launch tier |
| React | @grapesjs/react (MIT) or the plain JS API | Official react-email-editor component |
| Vue | Plain JS API or a community wrapper — no official package | Official vue-email-editor component |
| Angular | Plain JS API or a community wrapper — no official package | Official angular-email-editor component |
| Next.js | Client-only import; works in both routers | react-email-editor, client-only |
| Editor delivery | npm package bundled with your application | Script from editor.unlayer.com, with allowed domains registered |
| API | Full JavaScript API inside your app — no network hop | Editor JS API plus a hosted Cloud API from the Launch tier |
| Custom storage | Storage Manager posts to your endpoint | Design JSON returned to your app; file Custom Storage from Launch |
| Own database | Yours — any engine, any schema | Yours for design JSON; platform data stays with Unlayer |
| Self-hosting | Yes — you host every part of it | On-premise / offline deployment on the Enterprise tier |
| On-premise | Yes — no vendor infrastructure involved | Enterprise — inside your own VPC |
| Export | getHtml(), getCss(), getProjectData(); ZIP via plugin | exportHtml() returns HTML and JSON; image/PDF exports use credits |
| HTML output | Markup your own components emit | Markup Unlayer's renderer emits |
| MJML workflow | MJML preset plugin — author MJML, export email HTML | Not the pipeline; Unlayer has its own email renderer |
| Plugin ecosystem | 100+ marketplace listings plus the open npm ecosystem | Platform features by plan, plus custom tools you write |
| Backend control | Your application | Your application |
| Data architecture | Yours, end to end | Yours for content; platform features run on Unlayer's cloud |
| Authentication | Your application — GrapesJS ships none | Your application |
| Permissions | Your application — enforced by your backend | Your application; team collaboration and audit from Scale |
| Multi-tenancy | Your application | Your application |
| Publishing | Your application — the editor stops at the canvas | Your application |
| Analytics | Your application | Your application |
| AI | Your model, wired in as a command; community plugins exist | AI Assistant and AI Template Importer from Launch; metered AI credits |
| Pricing | $0 platform fee; you pay engineering, hosting and upkeep | Free tier, then published monthly plans; Enterprise quoted |
| Vendor dependency | An open-source package you can pin, patch or fork | Editor runtime and platform features come from Unlayer |
Unlayer capabilities and plan tiers read from unlayer.com and docs.unlayer.com on 2026-09-03; GrapesJS capabilities from the current release; marketplace listings verified 2026-09-03. Plan-gated features move between tiers — check Unlayer's own pricing page before budgeting.
"Control" is not one thing. With GrapesJS it splits three ways: what the engine already does, what you can add from the plugin ecosystem, and what only your application can answer. The third list is the longest, and pretending otherwise would waste your time.
6 areas
Everything inside the canvas, out of the box and customizable.
5 areas
Capabilities you install rather than write — or write once and reuse.
9 areas
GrapesJS ships none of these. They are yours either way — with Unlayer too.
GrapesJS does not automatically provide these backend systems. It gives your engineering team control over how they are implemented.
Not a screenshot and not a video. The frame below loads the real grapesjs package at version 0.23.6 — the same one you would install — so you can judge the canvas, the block drag, the style manager and the layer tree before reading another word about them.
This is the comparison most people arrive at this page for. Unlayer's email builder is ready the moment you load the SDK. With GrapesJS you assemble one: an email-safe component set on the canvas, MJML or table HTML on the way out, and your own sending infrastructure behind it.
Email pipeline
The email canvas itself: email-safe components, MJML export and the client constraints that shape both.
Read the guideHow the drag-and-drop mechanics work for email specifically, and what breaks when they are treated like web layout.
See the mechanicsWiring the email editor into a React application, including the client-only import and state boundaries.
See the React pathTemplates as a system: versioning, per-tenant overrides and the data model behind a reusable library.
See the template modelThe same editor foundation covers page building, because the canvas does not know what it is editing. Unlayer separates these into display modes; GrapesJS separates them by which components you register.
Putting an editor inside an application someone else's users log into — isolation, versioning and the surface you expose.
See how embedding worksPackaging the editor as a commercial feature: tenants, plans, limits and the pieces a product needs around a canvas.
See the SaaS modelCampaign pages and the publishing loop around them — drafts, previews, live URLs and measurement.
See the campaign loopVisual editing over content that already lives in a headless CMS, without turning the CMS into a page builder.
See the CMS pathUse one extensible editing foundation for multiple visual editing experiences.
This architecture matters when your own customers need the editor — not your marketing team. The editor becomes one feature among users, organizations, billing and permissions, and it has to behave like the rest of them.
Your SaaS
Your backend
Unlayer white-labels from its Launch tier upward, so this is not a capability only one side has. What differs is the depth: with GrapesJS the editor is your own code, so there is no boundary between "the editor's UI" and "your product's UI" to reconcile.
Panels, toolbar, icons and theme — the chrome around the canvas is markup you own.
Block names, categories, trait labels and empty states in your product's language, not the editor's.
Your domain, your session, your navigation, your support channel. Nothing announces a third party.
Instead of presenting users with a third-party editor, make visual editing feel like a native feature of your product.
Unlayer already hands your application the design JSON — the content is yours in both products. What GrapesJS adds is that there is no other party in the loop at all: the Storage Manager is an HTTP client pointed at an endpoint you wrote.
Persistence
// The editor is a client of YOUR API. Nothing is stored by GJS.Market.
grapesjs.init({
container: '#gjs',
storageManager: {
type: 'remote',
autosave: true,
stepsBeforeSave: 10,
options: {
remote: {
urlLoad: '/api/templates/42',
urlStore: '/api/templates/42',
// Your session, your headers, your authorization rules.
fetchOptions: (opts) => ({ ...opts, credentials: 'include' }),
},
},
},
});GrapesJS provides none of these databases and GJS.Market hosts nothing. The Storage Manager is a client of your API — your schema, your migrations, your backups, your authorization rules.
The blocks below are examples of what a registered component set looks like, not products for sale. Whatever your design system already ships — a hero, a product card, a pricing table, a form — becomes a block your customers can drag, with only the parts you allow left editable.
Your header, with your routes and your logo slot.
Headline, supporting copy and the CTA you actually ship.
A card bound to your catalogue rather than free-form markup.
Plans and intervals as traits, so the numbers stay consistent.
Quotes pulled from your own review data.
One button, one destination, no way to break the styling.
Fields wired to your endpoint, validation included.
The email capture block your growth team already approved.
// Your design system, as an editable component the user can drag in.
editor.DomComponents.addType('pricing-table', {
isComponent: (el) => el.dataset?.gjs === 'pricing-table',
model: {
defaults: {
traits: ['plan', 'currency', 'interval'],
// Only the parts you allow are editable in the canvas.
components: [{ type: 'text', name: 'Plan name' }],
},
},
});
editor.BlockManager.add('pricing-table', {
label: 'Pricing table',
category: 'Your design system',
content: { type: 'pricing-table' },
});Your customers can build with the components that belong to your product.
Both columns below are advantages. Neither is a strawman, and a team that reads only one of them will make a worse decision than a team that reads both.
Real advantages, and the reason Unlayer is the right answer for a lot of products.
Also real advantages — and each one is a decision your team now owns.
With greater control comes greater engineering responsibility.
"Unlayer is expensive, GrapesJS is free" is the wrong comparison. One approach converts cost into a subscription; the other converts it into engineering time. Both are real money, and which is cheaper depends entirely on your team.
| Plan | Monthly | Annual | What this tier adds |
|---|---|---|---|
| Free | $0 | — | All four builders — email, page, popup and document |
| Launch | $250/mo | $2,700/yr | White-labeling, custom storage, custom tools, Cloud API, AI assistant |
| Scale | $750/mo | $8,100/yr | Custom blocks, team collaboration, audit tab, built-in themes |
| Optimize | $2,000/mo | $21,600/yr | Custom themes, custom CSS, custom tabs, AMP, inbox previews |
| Enterprise | Quoted | — | On-premise / offline deployment, security and continuity commitments |
Plan names and list prices as published on Unlayer's pricing page, read on 2026-09-03. Tiers and gated features change — verify before budgeting.Unlayer pricing
Four capabilities are additionally metered and sold as recurring credit packs on top of a plan. Whether they matter depends on your volume — but a self-hosted editor has no equivalent meter, and that structural difference is worth knowing before you model costs.
No totals here, because an honest total needs your salary costs, your volume and your scope. What follows is the list of lines each approach puts on the invoice, so you can price them against your own numbers.
Predictable, external, and priced per month.
Front-loaded, internal, and priced in engineering time.
Neither column is a quote. Fill both in with your own figures over the horizon you actually plan for — three years is a common one — and compare the totals you get, not the ones anyone else asserts.
GrapesJS core has no recurring platform subscription, but your total implementation cost depends on your application.
Yes, for many applications that primarily need a customizable visual editing layer — but it is not a one-click drop-in replacement for every Unlayer platform capability. Here is the split, so you can check it against your own feature list rather than take the answer on trust.
9 items
In the box, on day one, with no tier to reach.
6 items
Installed rather than written — or written once, if nothing fits.
9 items
True with Unlayer as well. These were never the editor's job.
The rows that make a migration hard are rarely the canvas. They are the plan-gated platform features a team came to rely on — hosted previews, inbox testing, the AI importer — each of which becomes a build-or-integrate decision rather than a checkbox.
Audit
Inventory the existing Unlayer implementation: which display modes are live, which plan-gated features are in use, and which of them anyone would actually miss.
Components
Map the blocks and custom tools your users rely on to GrapesJS component types. This is where the real scope of the project becomes visible.
Templates
Identify which saved templates are genuinely reusable. Most libraries contain fewer distinct layouts than their file count suggests.
Data
Map the stored design JSON to your new content model. Unlayer's schema is its own; a converter is a piece of software you will write and test.
Editor
Integrate GrapesJS behind the same application surface, with your storage endpoint and your component set registered.
Rendering
Verify the output. For email that means real client testing; HTML that looks right in a browser is not evidence.
Testing
Re-run the workflows your users actually perform — duplicating a template, restoring a revision, sending a test — not just the happy path.
Rollout
Move users gradually behind a flag, with both editors readable during the overlap. Content migrations are much easier to reverse before the old editor is switched off.
Migration architecture
Migration is usually an architecture and content-model migration, not simply replacing one JavaScript package with another.
Every listing below is a real product in the GJS.Market catalogue, with its live name, price and thumbnail. Start with the GrapesJS core and add only the functionality your product needs.
Two honest gaps, as of 2026-09-03: the catalogue has no dedicated AI shelf — the AI listings above are individual plugins, and AI assistance in GrapesJS is generally a command you wire to your own model rather than a bundled assistant — and it has no roles, permissions or approval-workflow product, because those belong to your backend rather than to the editor.
Services
Most of the work in leaving a managed platform is not the editor — it is the architecture around it. If you would rather not discover that in production, the team behind this marketplace does the integration work as well as selling the plugins.
This section is here because a comparison that never recommends the other product is an advertisement. If any of the following describes your situation, adopting Unlayer is probably the better engineering decision.
The editor runtime, its updates and its uptime stop being your team's problem. For a small team shipping a secondary feature, that is worth real money.
A script tag and a display mode gets you a working four-mode builder. An equivalent GrapesJS integration is a project, not an afternoon.
If the block set, the output and the workflow already fit, customizing them is work you would be doing for its own sake.
Asset hosting, previews, inbox testing and template storage all have to run somewhere. On a managed platform, that somewhere is not your infrastructure.
Some teams would rather have a vendor, a contract and a roadmap than a repository. That is a legitimate strategy, not a compromise.
If several of these are true, take the managed platform. Fighting a product's defaults to save a subscription is a reliable way to spend more than the subscription.
See Unlayer's plansThe pattern in every row below is the same: visual editing is part of your product rather than a tool beside it, and the details your customers see are details you need to decide.
The editor lives inside your application, under your session and your navigation, and has to behave like the rest of it.
Your customers use the editor, so its limits, its block set and its output are product decisions, not vendor defaults.
Email-safe components you define, MJML or table HTML you control, and your own sending infrastructure behind it.
Nothing in the interface names a third party, because there is no third party in the page.
Air-gapped, on-premise or regulated deployments where no editor runtime may be fetched from an external origin.
Drafts, revisions, approvals and publishing that follow your existing content model rather than a new one.
One requirement per row, one verdict. Four rows go to Unlayer, three are genuinely a tie and one depends on the plan you are on — if a matrix hands every row to one product, it is a sales sheet rather than a comparison.
| Requirement | Better fit |
|---|---|
| Managed visual editor | Unlayer |
| Fast initial integration | Unlayer |
| Complete managed platform | Unlayer |
| No editor infrastructure to run | Unlayer |
| Embedded editor inside SaaS | GrapesJS |
| Maximum customization | GrapesJS |
| Custom backend | GrapesJS |
| Own storage architecture | GrapesJS |
| White-label product | GrapesJS |
| Editor framework | GrapesJS |
| Self-hosting | Depends on the plan |
| Custom components | Both |
| Email builder | Both |
| Page builder | Both |
Read the rows that match your requirements rather than counting them. One row that genuinely blocks you outweighs six that do not apply.
Unlayer gives you a managed visual editing platform. GrapesJS gives you an extensible editor foundation that you can integrate, customize, and connect to your own product architecture. Three ways to start, depending on how much of it you want to build yourself.
Tell us what the editor has to do inside your product and get a scoped plan for the integration.
Start with GrapesJSBlocks, storage adapters, email presets and editor shells — install what fits rather than writing it.
Explore pluginsArchitecture, migration and custom development from the team that maintains this marketplace.
Talk to an expertYour product. Your editor. Your data. Your workflow.
-thumbnail.jpg&w=3840&q=70)
