PageKit — the self-hosted GrapesJS site builder, sold as source. Get early access

HTML drag-and-drop builder

Build an HTML Drag-and-Drop Builder With GrapesJS

Visually build HTML pages with drag-and-drop components, edit styles without writing CSS by hand, and keep control of the HTML and CSS your application produces.

Start Building Try the HTML editor
Open sourceSelf-hostedHTML + CSS outputExtensibleEmbeddable

26k+

GitHub stars

1.4M+

Monthly npm downloads

100+

Plugins on GJS.Market

BSD-3-Clause

Core license

Visual · HTML · CSS

One Section, Three Views

This is the whole argument of the page in one component. The Visual tab is what your user drags and edits. The other two are what the editor hands back to your code — nothing hidden, nothing proprietary, just markup and stylesheet text you can store, transform and publish however you like.

<div id="editor">

What the user sees: blocks on the left, the page in the middle, style controls on the right.

Blocks

  • Hero
  • Text
  • Image
  • Button
  • Columns
  • Form
your-app.com/editor
section.hero

Build faster

Launch your next project.

Get started

Both code panes are the real return values of GrapesJS 0.23.6, re-indented for reading — each call actually returns a single line. Two details worth knowing before you build on them: getHtml() serializes the wrapper, so the result is enclosed in <body>…</body>, and getCss() writes shorthand declarations out as longhands and normalizes colors to rgb(). The stylesheet also starts with a small reset GrapesJS injects; getCss({ avoidProtected: true }) leaves it out.

The idea

Build HTML Visually Instead of Writing Every Layout by Hand

An HTML drag-and-drop builder lets users assemble page structures visually while your application remains in control of the underlying content, styling and publishing workflow.

Drag and drop

Users move blocks and components onto a canvas instead of editing a template file. You decide which blocks exist, where they may be dropped and what they may contain.

Visual editing

Content, layout and styles are edited through panels rather than by hand-writing every CSS rule. The editor turns those choices into ordinary stylesheet rules.

HTML + CSS output

Retrieve the resulting HTML and CSS as two plain strings and take them into your own application, your own storage and your own publishing workflow.

Definition

What Is an HTML Drag-and-Drop Builder?

It is an editor that lets a person assemble a web page by dragging pieces onto a canvas, adjusting them through controls rather than code, and getting real HTML and CSS out the other side. To do that convincingly, it has to combine all of the following into one coherent piece of software:

  • HTML components — every element on the canvas modelled as something the editor can reason about
  • A canvas that renders the page as the browser will, while staying editable
  • Drag and drop, with valid drop targets rather than free-floating boxes
  • Reusable blocks a user can pull in repeatedly
  • Style controls that write real CSS rules
  • Responsive editing per breakpoint
  • Asset management for images and media
  • Persistence, so a half-finished page survives a closed tab
  • Export and publishing of the finished HTML and CSS

The difference between a visual HTML editor and a simple drag-and-drop library is that the editor manages the entire editing state — selection, components, styles, commands, storage and output — as one system. A library moves a box across the screen; an editor knows what that box is, what it may contain, which CSS rule belongs to it, and how to serialize the result.

Live editor

Try a Real HTML Editor

Three public GrapesJS builds. Nothing loads until you click — the frames stay unrequested so this section costs you nothing on arrival.

Open in a new tab

The stock GrapesJS demo. Drag a block in, select it, change a style — then open the code view in its toolbar and watch the HTML and CSS change with you.

grapesjs.com/demo.htmlFree

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

Workflow

From Drag and Drop to Production HTML

  1. 1
    01

    Choose a block

    The user picks from the palette you defined. A block is a named, reusable starting point — a hero, a pricing table, a form — not an arbitrary empty div.

  2. 2
    02

    Drag it into the canvas

    The editor resolves where the block may legally land, inserts the component and selects it. Drop rules are yours to set per component type.

  3. 3
    03

    Edit content and styles

    Text is edited in place; layout, spacing, typography and color come from the Style Manager. Every change becomes a CSS rule the editor tracks.

  4. 4
    04

    Save the project

    The Storage Manager sends the editor state to whatever endpoint you point it at. This is the state needed to keep editing, not the finished page.

  5. 5
    05

    Export or publish HTML + CSS

    Call getHtml() and getCss(), then do whatever your product requires: sanitize, wrap in your layout, version, cache, deploy.

Editing surface

What Can Users Edit?

Exactly as much as you allow. Every one of these is something the editor can expose — and something you can lock down per component type so a marketer cannot break a layout an engineer designed.

Content

Text, headings, links and any content you mark editable. Components you would rather keep intact can simply be left non-editable.

Layout

Sections, columns, containers and the spacing between them, through the Dimension and Flex controls in the Style Manager.

Typography

Font family, size, weight, line height and alignment, written out as ordinary CSS declarations.

Colors

Text, backgrounds, borders and other visual properties. Values are serialized as rgb() in the emitted stylesheet.

Images and media

Handled through the Asset Manager, which you can point at your own upload endpoint or a storage provider.

Responsive styles

Rules scoped to a device. Styling while a breakpoint is active emits a matching media query rather than overwriting the base rule.

Components

Structured, reusable elements defined by you — the unit a block turns into once dropped, and the thing your app can recognize later.

Attributes and traits

Traits become the fields in the settings panel, so a custom component can expose a headline and a link target and nothing else.

Some of these are configuration rather than defaults. GrapesJS ships the Style Manager with General, Flex, Dimension, Typography, Decorations and Extra sectors out of the box; asset uploads, rich-text behaviour and per-component permissions are things you wire up — or install a plugin for.

Output

You Control the HTML and the CSS

A visual editor is only useful if the result can fit into your application. GrapesJS keeps two things separate, and the distinction matters more than any feature list: the state it needs in order to keep editing, and the markup your users actually receive.

From canvas to live page

  1. Visual editor
  2. Project state
  3. HTML + CSS
  4. Your backend
  5. Your publishing
publish.jsJS
// What the editor needs to keep editing — components, styles,
// pages, assets and symbols. Store this to resume a session.
const projectState = editor.getProjectData();

// What your users actually receive. Two plain strings.
const html = editor.getHtml();  // <body>…</body>
const css = editor.getCss();    // one line of CSS

// From here it is your application's decision: sanitize it, wrap it
// in your own layout, version it, cache it, put it behind your CDN.
await fetch(`/api/pages/${pageId}/publish`, {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ html, css }),
});
  • getProjectData() returns the editable state — pages, styles, assets, symbols and data sources. Store it to resume a session; it is not what you serve to visitors.
  • getHtml() and getCss() return strings. There is no runtime to install on the published page and no rendering service in the loop.
  • Sanitization, templating, versioning, caching and deployment stay on your side. That is a boundary, not a gap — it is what lets the output fit a product you already have.

A note on expectations: the emitted stylesheet is faithful, not hand-tuned. Shorthands come out as longhands, colors as rgb(), and a small reset is prepended unless you disable it. Treat the output as a reliable source you post-process, the same way you would treat the output of any build step.

Build vs start from a core

Why Build an HTML Editor From Scratch?

Every visual HTML editor needs the same set of subsystems before it can do anything interesting. The question is not whether you will need them — it is whether writing them is the part of your product worth your team's next six months.

What an HTML editor needs before it edits anything

  • Editable canvas
  • Drag and drop
  • Component model
  • Selection
  • Block palette
  • Style controls
  • Breakpoints
  • Asset library
  • Undo / redo
  • Serialization
  • Storage
  • HTML output
  • CSS output
  • Plugin API
Build it yourself

You own all fourteen

And you own them permanently: the canvas that has to stay editable while rendering like a browser, the drop-target logic, the undo stack that survives everything else, the serializer that turns your in-memory tree back into markup — plus every bug report against them for as long as the product lives.

Start with GrapesJS

You start where those already work

The canvas, drag and drop, component model, Block Manager, Style Manager, Device Manager, Asset Manager, undo history, Storage Manager and the HTML/CSS output APIs come with the core. What you write is the part that is specific to your product.

This is not a claim that GrapesJS is your whole product. Storage, authentication, permissions, publishing, sanitization and every product-specific workflow remain yours — see the architecture diagram below for exactly where the line falls.

See where the line falls
Subsystem by subsystem

What You Write, and What Already Exists

The right column is not a promise that a subsystem is finished for your use case — it names the part of GrapesJS you extend instead of the blank file you would otherwise start from.

Editor subsystemBuild yourselfStart with GrapesJS
CanvasBuildEditor foundation
Drag and dropBuildEditor foundation
Component modelBuildDomComponents
BlocksBuildBlock Manager
Style controlsBuildStyle Manager
Responsive editingBuildDevice Manager
AssetsBuildAsset Manager
Undo / redoBuildCommands and history
StorageBuildStorage Manager
HTML outputBuildeditor.getHtml()
CSS outputBuildeditor.getCss()
Custom componentsBuildDomComponents.addType
Plugin architectureBuildExisting plugin API
Auth and permissionsBuildYour application
SanitizationBuildYour application
PublishingBuildYour application

The last three rows are the honest ones. Nothing about embedding an editor removes your responsibility for who may edit what, what gets stored, and what reaches the public.

Architecture

How an HTML Drag-and-Drop Builder Fits Into Your Application

The editor is one layer of your product — not the product itself. Your application keeps the users, the permissions, the data and the decision about what goes live.

Your application

You own the surface

  • Users
  • Auth and permissions
  • Routing
  • Billing
  • Navigation

Embedded layer

GrapesJS visual editor

Extend it with plugins
  • Canvas
  • Blocks
  • Components
  • Styles
  • Assets
  • Devices

  • Persistence

    Your API

    • Storage Manager
    • Autosave
    • Versions

  • Data

    Your database

    • Projects
    • Pages
    • Assets

  • Delivery

    Your publishing

    • Preview
    • Approval
    • Live HTML
GrapesJS provides the visual HTML editing layer. Everything above and below it — who is editing, what is stored, what is published — stays inside the application you already have.
Under the hood

The Building Blocks Behind the Editor

Five managers do most of the work. You will meet them within an hour of starting, so it is worth knowing what each is responsible for.

Components

HTML elements represented as editable components, with their own rules about what they contain, whether they can be dragged and which properties they expose.

Block Manager

The palette. Blocks are what users drag; each one names the component it becomes. The core ships an empty palette, so what appears there is entirely your decision.

Style Manager

Visual CSS property controls, grouped into sectors — General, Flex, Dimension, Typography, Decorations and Extra by default. Sectors and properties are configurable.

Storage Manager

Persists project state to local storage, a remote endpoint, or a storage adapter you write yourself. Autosave is a config flag.

Asset Manager

Images and media: the picker users see and the upload path behind it, which you point at your own endpoint or a provider plugin.

Read the GrapesJS documentation
Custom components

Create Your Own HTML Components

This is where an HTML builder stops being generic. Define a component type, decide what it renders, and expose only the properties users should control — the rest of the markup stays exactly as your engineers wrote it.

hero-block.jsJS
// A block is what the user drags out of the panel.
editor.BlockManager.add('hero', {
  label: 'Hero',
  category: 'Sections',
  content: { type: 'hero' },
});

// A component type is what that block becomes on the canvas — and the
// only place you decide what the user may change about it.
editor.DomComponents.addType('hero', {
  model: {
    defaults: {
      tagName: 'section',
      attributes: { class: 'hero' },
      components: '<h1 class="hero__title">Build faster</h1>',
      // Traits become the fields in the settings panel.
      traits: [{ type: 'text', name: 'headline', label: 'Headline' }],
      droppable: false,
    },
  },
});
Read the Components API
Block → component → output

The Block Is Not the Component

Four things share a name in most tutorials and are genuinely different. Keeping them apart is the difference between a builder you can maintain and a pile of HTML strings.

  1. Block
  2. Component
  3. Traits
  4. Markup
  5. Your application

Block

What the user drags

A palette entry: a label, a category and the content it inserts. Purely a starting point — it has no life after the drop.

Component

What it becomes

The type registered with DomComponents. It decides the tag, the default children, whether the thing is droppable, and how the editor treats it from then on.

Traits

What users may change

The fields in the settings panel. A trait is a deliberate hole in an otherwise sealed component — a headline, a link target, a plan id.

Markup

What comes out

The component serialized back to HTML, with the classes and attributes you defined, ready for whatever your backend does next.

Design this chain deliberately and non-technical users get real freedom inside boundaries you chose. Skip it and you have shipped a text editor that emits divs.

Blocks

Start With Ready-Made HTML Blocks

These are the section types nearly every builder needs on day one, described by the markup they emit rather than by how they look. Build them against the Block Manager API, or install a block plugin and start from a full palette.

  • Hero

    A section with a heading, a supporting paragraph and a link styled as a button.

  • Header

    A header with a logo element and a nav list that collapses on narrow widths.

  • Features

    A container of repeated cards, each with an icon slot, a heading and body copy.

  • Pricing

    Plan cards with a price element, a feature list and a call-to-action link.

  • Testimonials

    Blockquote elements with a citation and an optional avatar image.

  • Gallery

    An image grid whose sources are filled from the Asset Manager.

  • CTA

    A single centred section with one heading and one primary link.

  • Forms

    A form element with labelled inputs and an action you point wherever you like.

  • Footer

    Link columns, legal text and secondary navigation in a footer element.

Browse block plugins

Worth being precise about: these are examples of block types, not a list of things built into GrapesJS. The core starts with an empty Block Manager on purpose — which palette your users get is a decision you make, either by writing the blocks or by installing one of the block plugins further down this page.

Use cases

What Can You Build?

The same editing core, pointed at six different problems. Each of these needs HTML-level control for a different reason.

HTML page editor

Give users a visual way to edit pages that already exist as HTML. Because the editor round-trips markup, you are extending your current pages rather than migrating them into someone's proprietary format.

WYSIWYG page builder

Landing page builder

Let marketers assemble campaign pages from blocks your team designed, with the classes and structure your design system expects still intact in the output.

Landing page builder

SaaS page builder

Embed visual editing as a feature of your product. Customers build pages inside your app, on your domain, stored in your database.

SaaS page builder

CMS visual editor

Add a visual layer to a content platform without replacing it. The editor produces HTML the CMS already knows how to store and render.

Headless CMS editor

Email builder

Email HTML is its own discipline — tables, inline styles, client quirks. GrapesJS handles it through the MJML and newsletter presets rather than the web-page path.

React email builder

Embeddable editor

Ship the editor inside an existing dashboard, behind your own authentication and navigation, with no redirect to a third-party site.

Embeddable page builder
Audience

Who Uses an HTML Visual Editor?

Different teams arrive here for different reasons, but the requirement is the same: visual editing that does not cost them control of the markup.

Developers

Add visual editing to an application that already exists, without adopting a platform or rewriting the front end around someone else's runtime.

SaaS teams

Turn page creation into a feature customers pay for, with the editor living on your domain and the data staying in your database.

CMS teams

Give content teams visual editing without replacing the CMS underneath, because what comes out is HTML the system already handles.

Agencies

Build one page-editing system with your own blocks and components, then reuse it across client projects instead of rebuilding per engagement.

Marketing platforms

Let users compose landing pages visually while your platform keeps the templates, the tracking and the publishing pipeline consistent.

Embedding

Embed the HTML Builder Into Your Product

You do not have to send users to another website to edit their pages. Mount the editor inside your own application and keep your existing authentication, navigation and backend.

Where the editor sits

  1. Your app
  2. Auth
  3. HTML editor
  4. Your API
  5. Database

In practice this is a route in your app that renders a container and initializes the editor against it. The user never leaves your domain, the session is the one they already have, and the project loads and saves through endpoints you wrote.

See the embeddable page builder guide
Storage

Save HTML Builder Projects to Your Own Backend

Point the Storage Manager at your API and every page becomes a row in your database, behind your own authentication. GrapesJS does not host anything, and neither does GJS.Market — no user content ever reaches us.

Two things to store, not one

  1. Editor state
  2. Your storage API
  3. Your database
  4. HTML + CSS
  5. Live page
editor-storage.jsJS
const editor = grapesjs.init({
  container: '#editor',

  // Editor state goes to your API, behind your own authentication.
  storageManager: {
    type: 'remote',
    autosave: true,
    options: {
      remote: {
        urlStore: `/api/pages/${pageId}`,
        urlLoad: `/api/pages/${pageId}`,
        fetchOptions: { credentials: 'include' },
      },
    },
  },
});

Keep the distinction sharp. Editor state is what the editor needs to reopen a page for further editing. Published output is the HTML and CSS a visitor receives. They have different lifecycles, different access rules and usually different tables — and a plugin can help with the wiring, but the architecture is yours.

Publishing

You Decide How HTML Gets Published

  1. 1
    01

    Edit

    The user works on the canvas. Nothing is public yet; the editor is only touching project state.

  2. 2
    02

    Save a draft

    Autosave or an explicit save writes the state through your storage endpoint, under your permission rules.

  3. 3
    03

    Preview

    Render the current HTML and CSS on a preview route so the author sees the real page, not the canvas.

  4. 4
    04

    Approve

    If your product needs review, this is your workflow — the editor has no opinion about who may sign off.

  5. 5
    05

    Publish

    Take getHtml() and getCss(), sanitize, wrap in your layout, version the result and write it wherever you serve pages from.

  6. 6
    06

    Live HTML

    The published page is plain HTML and CSS on your infrastructure. No editor runtime is required for a visitor to view it.

This is the clearest difference from a hosted page builder. There is no vendor deciding when your page goes live, on which domain it is served, or what happens to it if you stop paying.

Responsive

Build Responsive HTML Visually

The Device Manager switches the canvas between widths, and styles set while a device is active are written as a media query scoped to that width instead of overwriting the base rule. GrapesJS ships with Desktop, Tablet, Mobile landscape and Mobile portrait; the list and its widths are configuration, not a fixed set.

Desktopdefault
Tablet770px
Mobile portrait320px

What users can change per breakpoint

  • Spacing
  • Typography
  • Layout
  • Visibility
  • Alignment
  • Backgrounds

The widths shown are the GrapesJS defaults. Worth stating plainly: the editor defines the CSS rules — how a published page finally renders still depends on the markup and stylesheet you ship and the browser reading them.

Ecosystem

Extend Your HTML Builder With Plugins

Everything below is a real listing on GJS.Market, with the name, price and thumbnail rendered live from the catalogue. Grouped the way this page thinks about the problem: code and output first, then the panels around them.

Code and HTML editing

Let users — or your own developers — read and edit the markup and styles behind a component without leaving the editor.

Browse this category
Grapesjs Component Code EditorCode view

Grapesjs Component Code Editor

Opens the HTML and CSS of the selected component for direct editing — the fastest way to make the visual/code relationship obvious to a sceptical developer.

FreeView plugin
Code EditorCode editing

Code Editor

A code editing surface inside the builder for users who want to drop to markup for one section and stay visual everywhere else.

FreeView plugin

Export and publishing

Get the HTML and CSS out: as a downloadable bundle, converted server-side, or pushed straight to a host.

Browse this category
Export ZipExport

Export Zip

Packages the project's HTML, CSS and assets into a downloadable archive, for handing off a static site.

FreeView plugin
GrapesJS NodeJS JSON Converter to HTML/CSSServer-side output

GrapesJS NodeJS JSON Converter to HTML/CSS

Converts stored project JSON into HTML and CSS on the server, so publishing does not require a browser session.

FreeView plugin
Grapesjs NetlifyDeploy

Grapesjs Netlify

Pushes the generated output to a host directly from the editor, for products that want one-click publishing.

FreeView plugin

HTML blocks

Ready-made palettes, so the empty Block Manager is filled with sections rather than a blank panel.

Browse this category
Plugin Basic BlocksBase palette

Plugin Basic Blocks

A starting palette of common structural blocks, so day one is not spent writing Block Manager calls.

FreeView plugin
Plugin Blocky for Tailwind CSSTailwind blocks

Plugin Blocky for Tailwind CSS

Blocks that emit Tailwind utility classes, for teams whose output has to match an existing Tailwind design system.

$59.00View plugin

Style controls

Better CSS editing: class suggestions while typing, richer color and gradient pickers.

Browse this category
Ui Suggest ClassesClass suggestions

Ui Suggest Classes

Suggests existing CSS classes while typing in the Selector Manager, which keeps generated markup consistent rather than sprawling.

FreeView plugin
Grapesjs Style GpickrGradient picker

Grapesjs Style Gpickr

A gradient picker for the Style Manager, covering a case the default color control does not.

FreeView plugin

Custom components

Reusable, synchronized elements and tooling for turning your own markup into an editor component.

Browse this category
SymbolsReusable components

Symbols

Reusable component instances that stay in sync, so a header edited once updates wherever it appears.

FreeView plugin

Rich text

Extend the inline text editor so content editing feels like a document rather than a code field.

Browse this category
Grapesjs RTE ExtensionsRich text

Grapesjs RTE Extensions

Extends the built-in rich text editor with the formatting controls most content teams expect.

FreeView plugin

Assets and media

Connect the Asset Manager to real storage so images have somewhere to live.

Browse this category
Grapesjs CloudinaryMedia storage

Grapesjs Cloudinary

Wires the Asset Manager to Cloudinary, so uploads and transformations are handled outside your servers.

FreeView plugin

Storage

Persistence adapters for teams who would rather configure a backend than write one.

Browse this category
Grapesjs Firebase StorageRemote storage

Grapesjs Firebase Storage

A ready-made remote storage adapter, for prototypes and products already on Firebase.

FreeView plugin
IndexedDB StorageLocal storage

IndexedDB Storage

Keeps project state in the browser — useful for offline drafts and for demos with no backend at all.

FreeView plugin

Templates and presets

Preconfigured setups and template management, for starting from a working editor instead of an empty one.

Browse this category
Webpage PresetWeb preset

Webpage Preset

A configured web-page editing setup, closer to a working builder than a bare init call.

FreeView plugin
Templates ManagerTemplates

Templates Manager

Template management for products where users start from a chosen layout rather than a blank canvas.

$39.00View plugin

Email

Email HTML has its own rules. The MJML path exists for exactly that reason.

Browse this category
MJML PresetEmail preset

MJML Preset

The MJML path for email, where the output has to survive Outlook rather than a modern browser.

FreeView plugin
Browse HTML builder plugins
Stacks

Build Your HTML Builder Stack

Three starting configurations, assembled only from listings that actually exist. Treat them as a shape to adapt, not a bundle to buy.

Prices render live from the catalogue.

Approaches

HTML Drag-and-Drop Builder vs Other Approaches

These are not four products competing for the same job — they are four different trades. The point of the table is to make the trade explicit, not to declare a winner.

ConsiderationGrapesJSDrag-and-drop libraryHosted page builderBuild from scratch
Visual editor includedYesPartial — the gesture onlyYesWhatever you build
Control over HTML and CSSHigh — output is yours to post-processHigh — you write the markupVaries by vendorTotal
Self-hostedYesYesUsually notYes
Embeddable in your appYesYesDepends on the vendorYes
Component model and traitsBuilt inYou write itVendor's modelYou write it
Style controls and breakpointsBuilt inYou write themBuilt inYou write them
Time to a working editorDaysMonthsMinutesMonths to years
Product customizationHighHighBounded by the vendorUnbounded
Ongoing maintenanceYour integration, plus an upstream coreAll of the editorVendor'sAll of it, forever
License and costBSD-3-Clause core, $0 to useUsually permissiveSubscriptionEngineering time

Verified against the GrapesJS core (BSD-3-Clause, v0.23.6) on 2026-09-03. Hosted-builder rows are deliberately vague because their capabilities differ per vendor and change often — check the specific product you are considering rather than trusting a category-level claim.

Compare GrapesJS with the alternatives
Common mistake

A Drag-and-Drop Library Is Not a Page Builder

This is the single most expensive misjudgement in this space. A team picks a sortable-list library, ships a demo in a week, and then spends a year discovering what was missing.

What a drag-and-drop library gives you

Everything needed to move a box from one place to another, and nothing beyond it. Genuinely useful — for reordering a list.

  • Draggable elements
  • Drop zones
  • Movement
  • Sorting

What a visual HTML editor also has to manage

State that persists across every one of those gestures, and a serializer that can turn all of it back into markup a browser will render.

  • Component state
  • Selection
  • Styling
  • Blocks
  • Assets
  • Responsive controls
  • Undo / redo
  • Storage
  • Serialization
  • Export
  • Plugin architecture

Drag and drop is one interaction. A page builder is an entire editing system.

Quick start

Start Your HTML Drag-and-Drop Builder

One package, one container, one init call. Everything on this page grows from these few lines.

npm install grapesjs
editor.jsJS
import grapesjs from 'grapesjs';
import 'grapesjs/dist/css/grapes.min.css';

// Mount the editor on any container in your own application.
const editor = grapesjs.init({
  container: '#editor',
  height: '100vh',
  // Core ships no blocks: you decide what users are allowed to drag.
  blockManager: { blocks: [] },
});

The editor now runs but has an empty palette — the core deliberately ships no blocks. Register the first one, and the component type it becomes:

hero-block.jsJS
// A block is what the user drags out of the panel.
editor.BlockManager.add('hero', {
  label: 'Hero',
  category: 'Sections',
  content: { type: 'hero' },
});

// A component type is what that block becomes on the canvas — and the
// only place you decide what the user may change about it.
editor.DomComponents.addType('hero', {
  model: {
    defaults: {
      tagName: 'section',
      attributes: { class: 'hero' },
      components: '<h1 class="hero__title">Build faster</h1>',
      // Traits become the fields in the settings panel.
      traits: [{ type: 'text', name: 'headline', label: 'Headline' }],
      droppable: false,
    },
  },
});
  1. Install grapesjs
  2. Mount it on a container
  3. Register your blocks and component types
  4. Configure the Style Manager
  5. Point the Storage Manager at your API
  6. Publish getHtml() and getCss()

From here the work is product work: which blocks your users get, what they are allowed to change, and what your backend does with the markup that comes out.

Read the GrapesJS guide View the source on GitHub Browse developer tool plugins
Related guides

Related GJS.Market Guides

This page covers HTML-level editing and output. The neighbouring guides take the same core from other angles.

Drag-and-drop page builder

The broader guide to building a drag-and-drop page builder: the gesture, the blocks, the templates and the product decisions around them.

Read the guide

Open-source page builder

How to evaluate an open-source page builder — licensing, governance, extensibility and what self-hosting actually commits you to.

Compare the options

React page builder

Building a page builder inside a React application, and where a React-component model and an HTML-component model diverge.

Read the guide

GrapesJS React integration

The official React wrapper: mounting the editor as a component, managing its lifecycle and keeping it out of React's render loop.

See the integration
FAQ

HTML Drag-and-Drop Builder Questions

What is an HTML drag-and-drop builder?

An editor that lets a user assemble a web page by dragging pre-defined blocks onto a canvas and adjusting them through controls instead of code, while producing real HTML and CSS as the result. It combines a component model, a canvas, a block palette, style controls, responsive editing, asset handling, persistence and export into one system.

What is an HTML visual editor?

The same thing described from the editing side: a tool where changes are made by clicking, dragging and adjusting properties rather than by typing markup, and where what you see on screen corresponds to the HTML and CSS that will be published.

Can I build an HTML editor with GrapesJS?

Yes — that is what GrapesJS is for. It provides the canvas, drag and drop, the component model, the Block Manager, the Style Manager, the Device Manager, the Asset Manager, undo history, the Storage Manager and the HTML/CSS output APIs. You add the blocks, the component types, the backend and the publishing workflow.

Is GrapesJS an HTML editor?

GrapesJS is a framework for building HTML editors rather than a finished editing product. It ships an editing core with no blocks in the palette by default, precisely because which blocks your users get is meant to be your decision.

Can I drag and drop HTML elements?

Yes. Elements on the canvas are components that can be dragged, nested and reordered, and each component type can declare where it may be dropped and what it may contain — so a layout an engineer designed does not have to be breakable by a content editor.

Can I create custom HTML components?

Yes, with editor.DomComponents.addType(). You define the tag, the default attributes and children, whether the component is droppable or draggable, and which traits appear in the settings panel. A block then references that type as the thing it inserts.

Can I edit CSS visually?

Yes. The Style Manager exposes CSS properties as controls, grouped by default into General, Flex, Dimension, Typography, Decorations and Extra sectors. Which sectors and properties appear is configurable, so you can narrow the panel to only what your users should touch.

Can I export HTML and CSS?

Yes. editor.getHtml() returns the markup and editor.getCss() returns the stylesheet, both as plain strings. Two details are worth knowing: getHtml() serializes the wrapper, so the result is enclosed in a body element, and getCss() writes shorthand declarations out as longhand properties and normalizes colors to rgb().

Can I save HTML builder projects to my database?

Yes. The Storage Manager can be set to a remote type with load and store URLs pointing at your own API, including your own fetch options and credentials, so each project is simply a row in your database behind your existing authentication.

Can I connect the editor to my API?

Yes, and in more than one place: storage endpoints for project state, an upload endpoint for the Asset Manager, and whatever publish endpoint you call with the exported HTML and CSS. None of it routes through a third party.

Can I self-host an HTML page builder?

Yes. GrapesJS is an npm package that runs in the browser inside your own application. There is no hosted service in the path, no licence key check and no account required, so the editor works on an internal network or behind a firewall.

Can I embed an HTML editor into my SaaS?

Yes. Mount the editor on a container inside a route of your own application. Users keep your authentication and navigation, and the pages they build are stored by your backend rather than a vendor's.

Can I build a website builder with GrapesJS?

Yes. Multi-page editing, templates, assets and storage are all covered by the core plus available plugins. What distinguishes a website builder from a single-page editor is mostly the page management and publishing layer you build around the editor.

Can I build a landing page builder?

Yes, and it is one of the most common uses. Define the blocks your design system allows, expose a limited set of traits, and marketers can assemble campaign pages that still emit the classes and structure your engineers expect.

Can I build an email builder?

Yes, but through the email path rather than the web-page path. Email HTML has its own constraints, so GrapesJS covers it with MJML and newsletter presets that emit table-based, inline-styled markup instead of modern layout CSS.

Can I use GrapesJS with React?

Yes. There is an official React wrapper published as @grapesjs/react, licensed MIT, which mounts the editor as a component and manages its lifecycle. The editor core itself is framework-agnostic and works the same underneath.

Can I use GrapesJS with Next.js?

Yes, with one caveat: the editor needs the DOM, so it must not be server-rendered. Load it in a client-only component or a dynamic import with SSR disabled, and initialize it after the container exists.

What is the difference between a drag-and-drop library and a page builder?

A drag-and-drop library provides one interaction — draggable elements, drop zones, movement and sorting. A page builder also has to manage component state, selection, styling, blocks, assets, responsive rules, undo history, storage, serialization, export and a plugin architecture. Drag and drop is a gesture; a page builder is an entire editing system.

Is GrapesJS free for commercial use?

The GrapesJS core is published under the BSD-3-Clause license, which permits commercial use, modification and distribution subject to its attribution and non-endorsement conditions. The official React wrapper, @grapesjs/react, is MIT. Plugins and templates sold on GJS.Market carry their own licenses, listed on each product page. Read the license text yourself before shipping — this is a summary, not legal advice.
Get started

Build Your HTML Drag-and-Drop Builder

Start with GrapesJS, give users a visual HTML editing experience and keep control of your application, data and publishing workflow.

Start building

Install the editor

One npm package and an init call. You will have a working canvas before you finish your coffee.

Try GrapesJS
Extend

Add what you would rather not write

Block palettes, code views, style controls, storage adapters and export tooling — real listings, real prices.

Browse GJS.Market plugins
Learn

Read the documentation

Components, blocks, styles, storage and the plugin API, straight from the upstream project.

Read the builder guide

Drag. Drop. Edit HTML. Own the output.

More on building editors with GrapesJS:

Drag-and-drop page builderOpen-source page builderReact page builderGrapesJS React integrationSaaS page builderEmbeddable page builderWYSIWYG page builderReact email builderPage builder alternatives