Ship pages, not tickets
Click this text and type over it.
PageKit — the self-hosted GrapesJS site builder, sold as source. Get early access
Give your users a visual editor for building web pages with drag-and-drop components, reusable blocks and responsive styling — without building the editor infrastructure from scratch.
26k+
GitHub stars
1.4M+
Monthly npm downloads
100+
Plugins on GJS.Market
BSD-3-Clause
Core license
Drag a block from the palette into the canvas — or tap a block, then tap the canvas. Edit the text in place, adjust spacing and radius, and switch the viewport to see the layout adapt. This is a model of the interaction; the real GrapesJS editor is one section below.
Blocks
Drag a block in — or tap a block, then tap the canvas.
Click this text and type over it.
Three columns on desktop, one on mobile.
Styles
Accent
Three public GrapesJS builds, loaded only when you ask for one — nothing is fetched until you click.
The stock GrapesJS demo: block palette on the right, canvas in the middle, style manager and layer tree. Everything you see here is in the open-source core.
Loads a third-party demo in an iframe. Nothing is requested until you click.
One page, start to finish
Six subsystems that ship with the core, and that your users experience as one gesture.
Move blocks and components directly onto the canvas, and reorder them once they are there.
Edit content and styles on the page itself — typography, spacing, colour and background, without a stylesheet.
Adapt layouts for different screen sizes using the editor's device manager and breakpoints.
Build sections once and reuse them across pages, so a change in one place lands everywhere.
Manage images and other media through the Asset Manager, pointed at whatever storage you already use.
Connect the editor to your own publishing workflow — GrapesJS hands you HTML and CSS, you decide what happens next.
Every one of these is a subsystem you would otherwise design, build and maintain yourself.
GrapesJS is a self-hosted, open-source editor framework rather than a hosted builder product. That distinction is the whole reason it fits inside someone else's application.
Start from an open-source editor foundation. The core publishes as BSD-3-Clause and the official React wrapper as MIT — both permit commercial use, with no licence fee.
The editor runs inside your own infrastructure. No editor vendor sits between you and your users, and nothing leaves your stack unless you send it.
Create custom blocks, component types, commands and panels. The plugin API is the same one the ecosystem's own plugins are written against.
Replace panels, restyle the chrome, or drive the editor entirely from your own UI. The interface is not fixed — the demos above prove it.
The Storage Manager talks to your endpoints. Projects, pages, assets and users stay in your database, under your auth.
Extend the editor with plugins from GJS.Market and npm instead of writing every capability yourself.
The same editor core underneath, configured for a different job each time.
Let users create conversion-focused landing pages from a curated block set.
Landing page builderBuild complete multi-page websites with reusable layouts and shared navigation.
WYSIWYG website builderGive customers visual page creation as a feature inside your own application.
SaaS page builderAdd a visual editing layer to an existing content workflow instead of replacing it.
Headless CMS editorLet marketing teams assemble and update pages without opening a pull request.
No-code for developersGive clients controlled page-building — the blocks you allow, inside the frame you define.
White-label page builderDifferent reasons for wanting one, same problem underneath: page creation should not require a developer every time.
Add page creation as a product feature customers can use without leaving your app.
Build your own visual editing experience rather than reselling someone else's.
Put a visual layer on top of a content model you already have.
Create reusable page-building systems clients can operate between engagements.
Reduce the queue of routine layout and copy changes that currently land on engineering.
Start from an extensible editor core instead of a blank canvas and a drag-and-drop library.
A page builder is not one feature. It is a dozen subsystems that all have to agree with each other — and then keep agreeing as the product grows.
What a page builder actually contains
Canvas, drop targets, selection, the style panel, breakpoints, the asset library, multi-page state, persistence, an undo stack that survives all of it, export, publishing — and the ongoing maintenance of the lot.
The visual editor, drag & drop, blocks, components, Style Manager, assets, pages, storage APIs and the plugin system come with the core. What you add is the part that is specific to your product.
Build your product — not another page builder from scratch.
Neither column is free of work. The difference is which work is yours.
| Subsystem | From scratch | With GrapesJS |
|---|---|---|
| Editor canvas | Design and build it | In the core |
| Drag & drop | Drop targets, indicators, nesting rules | In the core |
| Blocks | Define the format and the palette UI | Block Manager, plus ready-made block plugins |
| Components | Build a component model and traits | Component types with traits and custom behaviour |
| Style Manager | Build a visual CSS editor | In the core, sectors configurable |
| Responsive controls | Breakpoint state across the whole editor | Device Manager, extendable with plugins |
| Assets | Library, upload flow, picker | Asset Manager, pointed at your storage |
| Pages | Multi-page state and navigation | Page Manager |
| Storage | Serialization format and endpoints | Storage Manager against your API |
| Undo / redo | A command stack over every mutation | In the core |
| Export | HTML/CSS generation | getHtml() / getCss(), plus export plugins |
| Publishing | Yours | Yours — deliberately |
| Editor maintenance | Yours | Shared with an open-source project and its ecosystem |
Publishing stays in your column on purpose: it is the part that has to match your domains, your CDN and your release process.
GrapesJS is a layer inside your application, not a platform you hand your users over to. Your app keeps the users, the content and the publishing decision.
Your application
You own the surface
Persistence
Your API
Data
Your database
Delivery
Your publishing
For the mechanics of mounting the editor inside an existing app — iframes, routing, auth handoff — see the embeddable page builder guide
The editor's Device Manager switches the canvas between breakpoints, and styles set while a device is active apply only at that width.
What users can change per breakpoint
Let users adapt layouts, spacing, typography and visibility for different screen sizes. How a published page renders on a given device still depends on the markup and CSS you ship — the editor controls the rules, not the browser.
A block is a starting point a user drags in. These are the section types most page builders need on day one — build them yourself against the Block Manager API, or install a block plugin and start from a full palette.
Headline, supporting line and a primary action.
Logo and navigation, collapsing to a menu on small screens.
A column set for benefits, with icon, title and copy.
Plan cards with one highlighted as the recommended tier.
Quotes with an attribution and avatar.
An image grid filled from the Asset Manager.
A single, centred call to action.
A form wired to whatever endpoint you choose.
Link columns, legal text and secondary navigation.
These are block types, not products. The block plugins actually for sale are further down the page.
This is the distinction that decides whether GrapesJS is a website-builder toy or an editor core you can build a product on.
Block
An entry in the palette. Dragging it into the canvas inserts content — the block itself is not what lives on the page.
Component
What the block becomes once dropped. Components have their own type, traits, and rules about what can be nested, dragged or removed.
Custom Component
Register your own component type and the editor treats it as a first-class citizen: your traits, your toolbar, your constraints, backed by your data.
Because custom components are backed by your own code, a GrapesJS editor can edit things a generic website builder has no concept of — a pricing table wired to your plans, a product grid reading your catalogue, a form posting to your API.
Most users do not want an empty page. Ship a set of starting layouts and let them save their own — presets configure the whole editor, templates give users a page to begin from.
The layouts users typically ask for
These are layout categories, not catalogue listings — what you would build or curate for your own users. The presets and template managers you can actually install are in the plugin section below.
The Storage Manager is a client of your API, not a service. Point it at your endpoints and the editor loads and saves through them.
Where the data goes
const editor = grapesjs.init({
container: '#editor',
// Each page is a row in your database, behind your own auth.
storageManager: {
type: 'remote',
autosave: true,
options: {
remote: {
urlStore: `/api/pages/${pageId}`,
urlLoad: `/api/pages/${pageId}`,
fetchOptions: { credentials: 'include' },
},
},
},
});
// Publishing stays on your side — your domains, your CDN, your workflow.
async function publish() {
await fetch(`/api/pages/${pageId}/publish`, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ html: editor.getHtml(), css: editor.getCss() }),
});
}Connect GrapesJS to your own backend and decide how projects, pages, assets and users are stored. GJS.Market sells plugins — it does not host your data.
The user builds the page
Drag, drop, edit and style on the canvas. Autosave keeps work in progress recoverable.
Persist through your API
The Storage Manager posts the project to your endpoint. Nothing is published yet.
Render it the way visitors will
Export HTML and CSS and render a preview on a route only the author can reach.
Your workflow, your rules
Approvals, scheduling, versioning — whatever your product already does. GrapesJS is not in this step.
Served from your infrastructure
Your domains, your CDN, your caching. The page is plain HTML and CSS.
GrapesJS handles the editing experience. Your application controls the publishing workflow.
Every card below is a real listing — names, prices and thumbnails render live from the catalogue, so nothing on this page can drift from what is actually for sale.
A clearer drop indicator, so users can see exactly where a block will land before they release it.
Drag-to-adjust margin and padding handles, so spacing is set on the canvas instead of in a number field.
Persists projects to Firebase when you would rather not build a storage endpoint first.
Keeps a recoverable copy of work in progress, so a closed tab does not cost the user their page.
Four starting configurations. Each is a real basket of listings, not a bundle SKU — install what you need and drop the rest.
For marketing pages that have to convert
For multi-page sites with shared layouts
WYSIWYG builderFor page creation inside your product
For a visual layer over existing content
Prices render live from the catalogue.
Two files and you have an editor on screen. Everything after that is configuration.
npm install grapesjsimport grapesjs from 'grapesjs';
import 'grapesjs/dist/css/grapes.min.css';
// The editor core. Mount it on any container in your app.
const editor = grapesjs.init({
container: '#editor',
});Then define what users can drag, and what it becomes once they drop it:
// A block is what the user drags. A component is what it becomes
// on the canvas once dropped — and what your app can then control.
editor.BlockManager.add('pricing-table', {
label: 'Pricing',
category: 'Sections',
content: { type: 'pricing-table' },
});
editor.DomComponents.addType('pricing-table', {
model: {
defaults: {
// Lock the frame, let the user edit only what you allow.
draggable: 'main, section',
traits: ['plan', 'currency'],
},
},
});From here the work is product-specific: which blocks your users get, which component types you register, and where projects are stored.
The core is framework-agnostic — it mounts on a DOM container. These pages cover the wiring for each.
No framework at all: import the core, mount it on a container, done.
HTML drag-and-drop builderThe official @grapesjs/react wrapper (MIT) handles mounting and teardown.
GrapesJS with ReactClient-only mount, dynamic import, and the SSR pitfalls to avoid.
Next.js page builderMount inside a component and clean up on unmount.
GrapesJS with VueWrap the editor in a component and keep it outside change detection.
GrapesJS with AngularOnly characteristics that can be checked against each project's published package and documentation. Capabilities differ by design goal — Craft.js is headless by intent, Puck is React-first, Builder.io is a hosted platform.
| Characteristic | GrapesJS | Puck | Craft.js | Builder.io |
|---|---|---|---|---|
| Open source | Yes — BSD-3-Clause | Yes — MIT | Yes — MIT | SDKs MIT; platform proprietary |
| Self-hosted | Yes | Yes | Yes | Hosted service |
| Framework | Framework-agnostic; React wrapper available | React | React | SDKs for several frameworks |
| Custom blocks | Yes — Block Manager | Yes — component config | Yes — user components | Yes — registered components |
| Custom components | Yes — component types with traits | Yes — React components with fields | Yes — React components with settings | Yes — with inputs |
| Custom editor UI | Yes — panels replaceable, or drive it headlessly | Provided UI, themable | Bring your own — no UI included | Vendor UI |
| Own storage backend | Yes — Storage Manager against your API | Yes — you persist the data | Yes — you persist the state | Content stored in Builder.io |
| Own publishing | Yes | Yes | Yes | Through Builder.io APIs |
| Plugin ecosystem | Yes — GJS.Market and npm | Growing | Small | Vendor integrations |
Licences verified against the npm registry on 2026-09-03: grapesjs 0.23.6 publishes as BSD-3-Clause; @measured/puck, @craftjs/core and @builder.io/react publish as MIT. Capabilities reflect each project's public documentation — check them before making a decision.
Same editor core, different question. If one of these matches your situation more precisely, start there.
The business case for adding a builder to a SaaS — what customers get and how it is packaged.
SaaS page builderThe technical walkthrough for mounting the editor inside an existing application.
Embeddable page builderBranding, theming and multi-tenancy when the editor has to look like yours.
White-label page builderThe licensing and self-hosting picture, in full.
Open source page builderStart with GrapesJS, customize the editing experience and extend it with the plugins your product needs.
Blocks, templates, storage, assets, export and AI — real listings with real prices.
Browse Page Builder PluginsInstall the core, mount the editor and register your first block. Nothing to sign up for.
Start BuildingCustom components, editor UI, integration with your backend — tell us what the builder has to do.
Need Custom Development?