Open source · Self-hosted

Build Your Own Open-Source Page Builder

Build a visual page builder you can self-host, customize and extend. Use GrapesJS as the open-source editing engine, and add the functionality your product needs with plugins.

Start building Explore plugins Compare page builders

Open sourceSelf-hostedCustomizableExtensibleNo editor vendor lock-in

Blocks, canvas and style controls — running inside your application, on your infrastructure.

26k+

GitHub stars

BSD-3-Clause

Core licence

1.4M+

Monthly npm downloads

100+

Plugins on GJS.Market

What open source buys you

What Does an Open-Source Page Builder Give You?

Open source is not a feature list — it is a set of rights over the editor in your product. These are the six that change how you build.

Code control

The editor's source is readable. You can trace a behaviour to the line that causes it, patch it, and fork it if you ever have to.

Self-hosting

GrapesJS is a client-side library you bundle. Nothing calls home, and the editor keeps working regardless of anyone else's uptime.

Data ownership

Projects, pages and assets go into your database through a storage adapter you write. The editor never sees a server you do not control.

UI control

Panels, buttons, sectors and the whole surrounding shell are yours to arrange. Your users do not have to meet a generic editor UI.

Integration freedom

Your APIs, your authentication, your asset storage, your publishing pipeline. The editor calls the functions you give it.

No editor vendor lock-in

Your core editing experience is not licensed from a hosted platform, so nobody else's pricing or roadmap decides whether your product still works.

The misconception

Open Source Doesn't Mean Building Everything From Scratch

The most expensive mistake teams make here is treating "we want to own our page builder" and "we have to write a visual editor" as the same sentence. They are not.

Open source

Build everything yourself

Open source

OwnCustomizeExtend

The goal isn't to reinvent every part of a visual editor. It's to start from an open-source foundation and spend your engineering time on the product that makes your application unique.

That is a reframing, not a promise of free lunch. An open-source foundation removes the canvas, the component model and the styling engine from your backlog. It does not remove your backend, your publishing workflow, or the work of keeping a dependency current — those move onto your plate the moment you self-host.

Scratch vs foundation

Build a Page Builder From Scratch, or Start With Open Source?

A useful comparison has to be honest about which capabilities arrive working, which arrive as an API you still have to use, and which are simply yours either way. This table separates those three.

Capability	Build from scratch	Open-source foundation
Visual canvas	Build it	Built in
Component model	Build it	Built in
Drag & drop	Build it	Built in
Blocks	Build it	API built in — content is yours
Styling	Build it	Built in
Responsive editing	Build it	Built in — you configure it
Assets	Build it	Built in — you configure it
Rich text	Build it	Built in
Undo / redo	Build it	Built in
Storage	Build it	Connect your backend
Publishing	Build it	Build your workflow
Custom editor UI	Build it	Built in — you configure it
Plugin architecture	Build it	Built in
Product logic	Build it	Your application

Verified against grapesjs 0.23.6 on 2026-09-03 by running each API in a browser, not by reading a feature list. "Built in" means the module ships in the core package; "API built in" means the mechanism ships but the content does not.

See the architecture

Open source gives you a head start without taking control away from you.

The engine

Why Use GrapesJS as Your Open-Source Page Builder Engine?

GrapesJS is a framework-agnostic visual editor you install from npm and mount into your own UI. These are the parts of it you will actually build on — and where each one stops.

Core

Visual editing

A canvas your users compose in directly: select, move, nest and edit real DOM rather than a preview of it.

Core

Components

Reusable content structures with typed traits, so a marketer edits a headline in a form field instead of a div.

Core API

Blocks

The draggable panel is core; the blocks in it are not. You register your own, or install a block plugin.

Core

Styling

A style manager with sectors and selectors, so users change how something looks without touching CSS.

Core

Responsive editing

Device breakpoints are a core module. You define which devices your product offers and what widths they map to.

Core API

Extensibility

A plugin is a function that receives the editor. That is the whole contract, and it is why an ecosystem exists at all.

Core

HTML / CSS workflows

Output is HTML and CSS you can read, diff and serve. Useful when the thing you are building is genuinely for the web.

Via plugins

Email workflows

Email is not in the core package. MJML and newsletter presets add it — a real capability, but an installed one.

Read the GrapesJS docs

Who owns what

GrapesJS Handles the Editor. Your Application Handles the Product.

Every layer between "open source" and "a page builder you own" belongs to someone. Being clear about which ones are yours is the difference between a realistic plan and a surprise.

Open SourceOpen source
↓
GrapesJSOpen source
↓
Your ApplicationYou own it
↓
Your BackendYou own it
↓
GJS.Market PluginsOptional
↓
Your Page BuilderThe result

Open source

GrapesJS

The open-source visual editing foundation: canvas, components, blocks, styles, assets and the plugin contract.

You own it

Your Application

Authentication, dashboard, billing, users, permissions and the product experience around the editor.

You own it

Your Backend

Storage, projects, publishing, versions and the business logic that makes your product worth paying for.

Optional

GJS.Market Plugins

Optional blocks, integrations and specialized functionality — used where buying beats building, skipped where it doesn't.

You are not outsourcing your product. You are declining to rewrite a canvas.

Architecture

Build Your Own Page Builder Architecture

The editor is one layer, not the system. Here is where it sits, what surrounds it, and what it hands back — so you can see exactly how much of this diagram is code you have to write.

Your Product
Everything that makes your product yours. None of it comes from the editor.
- Authentication
- Billing
- Users
- Permissions
↓
React / Vue / Angular / Your UI
Whatever you already build in. GrapesJS is framework-agnostic and mounts into a container element.
↓
GrapesJS — Editor Foundation
The open-source layer. Installed from npm, configured by you, running on your infrastructure.
- Blocks
- Styles
- Assets
- Components
↓
Your Backend
Your API, your database, your rules. GrapesJS calls the load and store functions you write.
- Storage
- Versions
- Publishing
- Business Logic

GrapesJS handles the editing experience. Your application handles everything that makes your product unique.

See how the integration works

Use cases

What Can You Build With an Open-Source Page Builder?

Six products teams actually ship on this foundation. Each one is a different amount of work around the same editor.

SaaS page builder

Let your customers create and customize pages inside your product, with your components and your permissions.

Build a SaaS page builder

Website builder

Multi-page sites with visual editing. The Pages module is core; routing, domains and hosting are yours to build.

Build a website builder

Landing page builder

Give marketers a visual way to ship campaign pages without a deploy — and without leaving your design system.

Build a landing page builder

CMS visual editor

Add visual editing to a CMS or headless CMS, so editors see the page instead of a field list.

Build a CMS editor

Email builder

The same editor, pointed at email. MJML and newsletter presets handle the output; they are plugins, not core.

Build an email builder

Internal content tools

Custom visual editing for the team that keeps asking engineering to change a paragraph. No public product required.

Audience

Who Is an Open-Source Page Builder For?

Four situations where owning the editor is worth the work it costs.

SaaS founders

You want to give customers a visual editor without outsourcing the experience your product is judged on.

Product teams

You need visual editing inside an application that already exists, on the framework it already uses.

Developers

You want control over the editor architecture, the data model and every integration point.

Agencies

You want reusable visual editing infrastructure you can carry across client projects instead of relicensing per site.

When it fits

When Should You Choose GrapesJS?

GrapesJS is a good answer to a specific shape of requirement. If most of this list is your list, it fits.

Choose GrapesJS when you need:

self-hosting on infrastructure you control
an embeddable editor inside an existing application
control over the application architecture
customizable editing workflows
custom components and blocks
your own backend and data model
your own publishing pipeline
extensibility through plugins
HTML/CSS-oriented output
a SaaS integration rather than a standalone tool
a customizable editor rather than a fixed hosted platform

What you take on in exchange: you host it, you upgrade it, you write the storage and publishing layers, and you own the editor's behaviour when something breaks. That is a real cost, and it is the right one to pay only if the list above is genuinely your list.

Start with GrapesJS

When it doesn't

When Might Another Page Builder Be Better?

Three requirements where something else is the better tool. If one of these is your situation, GrapesJS will fight you.

A hosted platform
You want a managed product, not infrastructure
You get the editor, hosting, upgrades and support as one bill, and you give up source control, self-hosting and the ability to change the editor itself.
A React component editor
Your requirement is composing React components
If pages are trees of your own React components and never HTML you hand-edit, a React-first editor matches your data model more directly than an HTML/CSS-oriented one.
A complete website builder
You need the whole application, not a foundation
If you want a finished website-building product rather than an editor you embed, projects that ship the whole application will get you there far faster.

None of these is a weakness in the other tools. They are different products answering different questions, and picking the wrong category costs more than picking the wrong library.

Compare open-source page builders

Four different things

They Are Not All the Same Kind of Product

These projects are not interchangeable. Some are libraries you embed, some are applications you deploy, and comparing them on one undifferentiated feature list is how teams end up committed to the wrong category. They are grouped by what they are before they are compared on what they do.

Embeddable editor frameworks

Libraries you install from npm and mount inside an application you already have. You supply the UI, the backend and the publishing pipeline; the library supplies the editing.

In this group

GrapesJS

React editor frameworks

Libraries for building an editor over your own React component tree. A page is JSON describing components, not markup — which is the right model if your pages are already React.

In this group

Puck
Craft.js

Visual website builders

Applications you deploy and use, rather than libraries you build with. Far faster to a working site, and not designed to disappear inside someone else's product.

In this group

Silex
Webstudio

CMS / content platforms

Full content platforms where visual page building is one capability among content modelling, roles and publishing. You adopt the platform, not just the editor.

In this group

Webiny

The field

Best Open-Source Page Builders Compared

Capability	GrapesJS	Puck	Craft.js	Silex	Webstudio	Webiny
Licence	BSD-3-Clause	MIT	MIT	AGPL-3.0	AGPL-3.0	MIT*
Self-hosted	Yes — a client-side library you bundle	Yes	Yes	Yes — Docker, npm or source	Published sites yes; the docs advise against self-hosting the builder in production	Yes, but AWS only — the docs are explicit that nothing else is supported
Embeddable in your app	Yes — mount the library into any container element	Yes — “just a React component” in your tree	Yes, but it is a toolkit: you build the editor UI yourself	As a Node server. No documented front-end editor mount	No — the builder package is private and not published to npm	No — an iframe into a fully deployed Webiny stack
Visual editor	✓	✓	✓	✓	✓	✓
Drag & drop	✓	✓	✓	✓	✓	✓
Custom components	✓	✓	✓	✓	Not verified	✓
Responsive editing	✓	✓	Custom — you build it	Partial	✓	✓
Custom backend / storage	Storage API — your own load and store functions	onPublish / onChange — you save the data	serialize() / deserialize() — you save the JSON	Connector API for storage and hosting	No connector API; data leaves via CLI export	Storage is fixed at project creation and cannot be changed later
Plugin architecture	✓	✓	None — by design	✓	Not verified	✓
HTML / CSS output	✓	—	—	✓	✓	—
Email workflows	Via plugin	—	—	—	—	—
React	✓	✓	✓	Not the primary focus	✓	✓
Framework	Framework-agnostic	React	React	Framework-agnostic (built on GrapesJS)	React (React Router v7 output)	React (Next.js supported)
Verified version	grapesjs 0.23.6	@puckeditor/core 0.23.0	@craftjs/core 0.2.12	@silexlabs/silex 3.9.0	0.296.0	6.4.9
Latest release	Released 2026-08-26	Released 2026-08-07	No commits on any branch since 2025-02	Released 2026-07-26	Released 2026-09-01	Released 2026-08-27

Licences read from each repository's own LICENSE file, versions and deprecations from the npm registry, capabilities from each project's own documentation. Verified 2026-09-03. “Not verified” means we could not find a primary source either way — not that the capability is missing. A dash means the project does not target that use case. *Webiny's root licence carves out an enterprise directory and defers to per-package licences; on the current default branch that directory is absent and every per-package licence is MIT.

See the decision guide

Decision guide

Which Open-Source Page Builder Should You Choose?

Three questions, in the order that actually narrows the field. The first one eliminates more options than the other two combined.

Are you building a product around the editor, or looking for a finished tool?

A product — the editor lives inside my application
Keep going
You want a foundation you embed and control. Question 02 narrows which kind.
A finished tool — I want to build sites with it
Website builder
You want an application, not a library. Deployable open-source website builders will get you there far faster than any framework.
A content platform for a whole team
CMS platform
If page building is one requirement among publishing, roles and content modelling, start from a content platform instead.

What is a page in your product — markup, or a tree of your components?

Markup I can serve, export and diff
GrapesJS
HTML and CSS output, a framework-agnostic editor, and a storage adapter into your own database.
A tree of my own React components
React editor
If pages are component trees serialized as JSON and never hand-edited markup, a React-first editor is the closer fit.
Both, depending on the surface
GrapesJS + React
The official React wrapper mounts the editor as a React component while output stays HTML/CSS. This is the common case for SaaS.

Can you take on hosting, upgrades and the storage layer?

Yes — we run our own infrastructure
Self-host it
Install, configure, write a storage adapter, and the editor is genuinely yours.
Not right now
Hosted editor
A hosted platform trades control for someone else carrying the infrastructure. That is a legitimate trade, not a failure.
Yes, but we don't want to build every feature
Foundation + plugins
Self-host the editor and buy the pieces that aren't your product's differentiator.

The right choice depends on whether you need a complete website-building product or an editor foundation that becomes part of your own application. Everything else — licence, framework, plugin API — only matters once that question is answered.

Quick start

Start Building Your Open-Source Page Builder

Four steps from npm to a page builder wired into your backend. Every snippet below was executed against grapesjs 0.23.6 in a real browser before publication — not adapted from a changelog.

Your App
↓
GrapesJS
↓
Blocks · Components · Traits
↓
Your Storage API

01 — Install
Add GrapesJS to your application
One dependency. No build plugin, no framework requirement.
npm install grapesjs

02 — Initialize

Mount the editor

Point it at a container and choose your device breakpoints. This is a working editor.

Mount the editorjs

import grapesjs from 'grapesjs';
import 'grapesjs/dist/css/grapes.min.css';

const editor = grapesjs.init({
  container: '#gjs',
  height: '100vh',
  width: 'auto',
  // Reads the markup already inside #gjs as the starting page.
  fromElement: true,
  // No storage yet — step 04 connects your backend.
  storageManager: false,
  deviceManager: {
    devices: [
      { id: 'desktop', name: 'Desktop', width: '' },
      { id: 'tablet', name: 'Tablet', width: '768px', widthMedia: '992px' },
      { id: 'mobile', name: 'Mobile', width: '320px', widthMedia: '480px' },
    ],
  },
});

03 — Extend

Add blocks, components and plugins

A component type defines what users can edit; a block makes it draggable. They are two registrations, not one.

Add blocks, components and pluginsjs

// A component type owns its markup and the traits your users can edit.
editor.Components.addType('cta', {
  model: {
    defaults: {
      tagName: 'a',
      attributes: { class: 'cta', href: '#' },
      components: 'Get started',
      traits: [
        { name: 'href', type: 'text', label: 'Link' },
        { name: 'title', type: 'text', label: 'Title' },
      ],
    },
  },
});

// A block is what makes that type draggable from the panel — a separate,
// explicit registration, not something the type gives you for free.
editor.Blocks.add('cta-block', {
  label: 'CTA',
  category: 'Basic',
  content: { type: 'cta' },
});

04 — Connect

Connect storage, users and publishing

The storage adapter is where the editor stops and your product starts.

Connect storage, users and publishingjs

// Your backend, your schema, your auth. GrapesJS calls load() and store();
// everything inside them is yours.
editor.Storage.add('your-backend', {
  async load() {
    const res = await fetch(`/api/pages/${pageId}`, { credentials: 'include' });
    return res.ok ? res.json() : {};
  },
  async store(data) {
    await fetch(`/api/pages/${pageId}`, {
      method: 'PUT',
      credentials: 'include',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify(data),
    });
    return data;
  },
});

// Publishing is your workflow, not the editor's. getHtml()/getCss() give you
// the output; what happens to it is a decision only your product can make.
editor.Commands.add('publish-page', {
  run: (ed) => ({ html: ed.getHtml(), css: ed.getCss() }),
});

Verified against grapesjs 0.23.6 on 2026-09-03.

That is the whole surface: install, mount, extend, connect. Everything past step 04 — auth, billing, versions, domains — is your application, and none of it is decided by the editor.

Read the integration guide

Try it

The Editor, Running

Open fullscreen

The project's own demo — core editor, default panels, nothing bought.

grapesjs.com/demo.htmlFree

Loads a third-party demo in an iframe. Nothing loads until you click.

Ecosystem

Extend Your Open-Source Page Builder

Start with an open-source editor core. Add only the functionality your product needs — and build the rest yourself, where it is actually your differentiator.

This section is temporarily unavailable.

Browse all GJS.Market plugins

Browse by capability

Curated stacks

Three Starting Points

Not a bundle — three sets that cover the first real requirement in each of three common builds. Every item is a live listing, and every one of them is optional.

Starter stack

Your first visual editor

Read the tutorial

SaaS stack

A customer-facing page builder

Build a SaaS page builder

Email stack

Visual email creation

Build an email builder

Prices are read live from the catalogue.

Extend, don't replace

Missing a Feature? Extend the Editor.

Most "GrapesJS can't do X" conclusions are really "the core package doesn't ship X". Those are different problems, and only one of them requires a different editor.

Don't replace the editor because one feature is missing. Extend it.

Total cost

What Does an Open-Source Page Builder Really Cost?

Open source changes the economics of a page builder. It does not eliminate the engineering, and any page that tells you otherwise is selling something. Here is what you still own on each route.

Route A

Build everything yourself

You own:

editor architecture
canvas and component model
editing UX
the whole product on top
testing
maintenance
every future feature

Total control, and the longest path to a first working editor. Worth it only when the editor itself is your product's differentiator.

Route B

Start with GrapesJS

You still build:

your application
your backend
storage and versions
publishing
product-specific functionality
upgrades and hosting

The visual editing foundation already exists. Everything above is still yours to build — this list is shorter than Route A's, not empty.

Route C

Extend with plugins

You still build:

your application
your backend
the parts that are genuinely your product
integration and upgrade of what you install

Buying a block set or a storage adapter removes a task, not a dependency. Each one is code you now rely on and have to keep working.

We deliberately publish no dollar figure for "building a page builder from scratch". There is no credible public benchmark for it, the honest answer depends entirely on your team and scope, and an invented number would be the least trustworthy thing on this page. Count the surfaces above instead — they are the thing you are actually trading.

The other trade

Open Source vs Hosted Page Builders

This is a trade, not a ranking. Open source gives you more control; hosted gives you less to operate. Both columns contain things that will matter to you.

Dimension	Open source	Hosted
Source control	Yours to read, patch and fork	Limited to what the platform exposes
Self-hosting	Usually possible	Usually not
Data location	Your infrastructure	The provider's
UI customization	High — the shell is yours	Depends on the platform
Vendor dependency	Lower	Higher
Maintenance	Your responsibility	The provider's
Infrastructure	Your responsibility	The provider's
Extensibility	Depends on the project's plugin API	Depends on the platform's extension points
Time to a working editor	Integration work before anything is usable	Usable before you have written any code

Open source gives you more control, but you also take responsibility for infrastructure and maintenance. If nobody on your team wants that responsibility, hosted is the honest answer.

FAQ

Open-Source Page Builder Questions

What is an open-source page builder?

A visual page editor whose source code is published under an open-source licence, so you can read it, run it on your own infrastructure, modify it, and build a product on top of it. It can be a library you embed in your application, or a complete website-building application you deploy — those are very different things that share the same label.

What is the best open-source page builder?

There isn't one best — there is a best for your requirement. If you are embedding an editor into your own application and want HTML/CSS output, GrapesJS fits. If pages are trees of your React components, a React-first editor fits better. If you want a finished website-building application rather than a foundation, a deployable website builder will be faster. Answer "library or application?" first; it eliminates more options than any feature comparison.

Is GrapesJS open source?

Yes. The core grapesjs package is published under the BSD-3-Clause licence, and the official @grapesjs/react wrapper under MIT. Both are permissive licences. Note that GrapesJS core is not MIT, despite what a lot of comparison articles say.

Can I self-host GrapesJS?

Yes. GrapesJS is a client-side JavaScript library you install from npm and bundle with your application. There is no service to call and no account to create, so it runs wherever your frontend runs.

Can I use an open-source page builder for a SaaS?

Yes, and it is one of the most common uses. BSD-3-Clause is a permissive licence that allows commercial and proprietary use provided you keep the copyright notice and licence text in your distribution. Check each project's licence individually before you commit — some open-source page builders use AGPL-3.0, which carries obligations that matter specifically for hosted products.

Can I customize the editor UI?

Yes. Panels, buttons, style sectors and the surrounding shell are all configurable, and several published editors replace the default layout entirely while running the same core. If you want the editor to look like your product rather than like GrapesJS, that is a supported outcome, not a hack.

Can I connect the page builder to my own database?

Yes. GrapesJS has a storage API where you register an adapter with load and store functions. What happens inside them — which endpoint, which auth, which schema — is entirely yours, so project data goes into your own database rather than anyone else's.

Can I build a React page builder with GrapesJS?

Yes. The official @grapesjs/react wrapper mounts the editor as a React component, so it lives inside your component tree with your state and routing around it. The editor core itself stays framework-agnostic — the wrapper is an integration layer, not a rewrite.

Can I build a website builder with GrapesJS?

Yes, with a caveat worth being clear about. Multi-page editing is a core module, so the editing side is covered. Everything that makes it a website builder rather than a page editor — routing, domains, hosting, deploys, user accounts — is application code you write. GrapesJS gives you the editor, not the platform.

Can I build an email builder with GrapesJS?

Yes, using plugins. Email output is not in the core package: MJML and newsletter presets add the email-specific blocks and the output pipeline that survives real email clients. It is a real, production-used capability, but it is an installed one, not something you get by default.

Is GrapesJS free for commercial projects?

The core package is BSD-3-Clause and the React wrapper is MIT, and both permit commercial use, including in closed-source products, as long as you retain the copyright and licence notices. This is a summary of the licence text, not legal advice — read the LICENSE file in the repository, and ask your own counsel if the answer matters to a contract.

What is the difference between GrapesJS and Webstudio?

They sit in different categories. GrapesJS is a BSD-3-Clause library you install and embed inside your own application, where you supply the UI, backend and publishing. Webstudio is an AGPL-3.0 visual website builder — an application in its own right, with a hosted offering. The licences also differ in a way that matters for hosted products: AGPL-3.0 carries source-availability obligations that BSD-3-Clause does not.

What is the difference between GrapesJS and Puck?

Data model and framework. Puck is an MIT-licensed React editor: a page is a JSON tree of your React components, rendered by React. GrapesJS is framework-agnostic and works with HTML and CSS output, which suits products that serve or export markup. If your pages are React components, Puck maps to them more directly; if they are web pages, GrapesJS does.

What is the difference between an open-source and a hosted page builder?

Who carries the work. With open source you get the source, self-hosting, your own data location and deep UI control — and you take on hosting, upgrades and maintenance. With a hosted builder the provider carries all of that, and you accept their pricing, roadmap and limits on customization. Neither is universally better; it depends on whether operating the editor is a cost you want.

Do I need GJS.Market plugins?

No. GrapesJS is fully usable without buying anything, and plenty of production editors are built entirely on the core plus code the team wrote. Plugins are worth it when a capability isn't your product's differentiator — an email preset, a block set, a storage adapter — and not worth it when it is.

Can I create custom blocks and components?

Yes, and it is the normal way to use the editor. You register a component type that defines the markup and the traits users can edit, then register a block that makes it draggable from the panel. They are two separate registrations, which is worth knowing before you wonder why your new component isn't in the panel.

Get started