Build a Drag-and-Drop Email Builder with GrapesJS

This is a real GrapesJS editor running on this page — not a video and not a screenshot. Drag a block in from the right, select anything to restyle it, switch to the phone width, then read the markup back out. The header and footer are locked, which is the same pattern the section further down explains.

A drag-and-drop email builder is a visual editor that lets users create email layouts from reusable components instead of manually writing HTML tables and email-specific CSS.

The difference is who has to know the rules. Without a builder, whoever writes the email needs to know that layout is done with nested tables, that most styling has to be inline, and that a stray margin can collapse the design in one client. With a builder, those rules are encoded once — by you — into blocks and components, and everyone else just arranges them.

<table role="presentation" cellpadding="0" cellspacing="0" width="600">
  <tr>
    <td style="padding:32px;font-family:Arial,sans-serif">
      <h1 style="margin:0 0 12px;font-size:26px">Welcome</h1>
      <p style="margin:0;font-size:15px;line-height:1.6">Your content…</p>
    </td>
  </tr>
</table>

The builder is not there to make email easy. It is there to make the hard parts somebody else's decision — yours, made once, at the component level.

A web page runs in a browser you can broadly reason about. An email runs inside whatever client the recipient opened it in, and that client may rewrite your markup, strip your styles, or lay it out with a different engine entirely. A builder for email therefore has to constrain what users can produce, not just make production pleasant.

You are not building an editor that produces beautiful HTML. You are building an editor that cannot produce dangerous HTML.

Client behaviour changes with releases and rendering modes, so this page states no per-client support matrix. Validate against the clients and features your own audience actually uses. Last reviewed 2026-09-03.

GrapesJS never talks to your database and never talks to your email provider. It hands you a document; everything after that is your architecture.

Three owners, no overlap. The most common architectural mistake on this page's topic is expecting the editor to do something in the right-hand columns.

Nothing in the right-hand columns is a GrapesJS gap — those rows were never the editor's job. Treating them as application work from the first sprint is what keeps the integration simple.

Three artefacts come out of the same canvas, and they are not interchangeable. One is the project you keep, two are the delivery formats you generate from it.

JSON is the project. HTML and MJML are the delivery. Store the first, generate the others.

Do not hand users a blank canvas and a div. Ship a small set of components that already encode the table markup, the inline styles and the fallbacks, then let people arrange them. These ten cover most of what marketing and lifecycle email actually needs.

• Header

  Logo, brand bar, preheader text. Usually locked so every email leaves with the same identity.

• Hero

  Headline, supporting line and one action. Sized so the message survives without the image loading.

• Text

  A paragraph block with a real font fallback stack and line height that holds up at phone widths.

• Image

  Fixed width, explicit dimensions and required alt text, so a blocked image still leaves a readable email.

• Button

  A table-based button rather than a styled anchor — the difference is visible in stricter clients.

• Two-column section

  A table row that stacks on narrow viewports, with the stacked order already decided by you.

• Product card

  Image, name, price and link, driven by fields your backend fills in rather than by copy-paste.

• Social links

  A fixed row of icons and URLs, editable as settings rather than as markup.

• Divider

  A rule drawn with a table border rather than an <hr> element, which several clients restyle.

• Footer

  Sender identity, address and unsubscribe link. Usually locked, because these are obligations.

A component is the definition; a block is how a user gets one onto the canvas. The block library is the single most powerful lever you have over what people can build — and the easiest one to get wrong by being generous.

Locking in GrapesJS is not a mode or a plan tier — it is a set of options on a component definition. A locked region still renders, still exports, and simply refuses to be dragged, deleted or restyled in the editor.

These options govern the editor UI. They are not authorisation. A modified project posted straight at your save endpoint is bound only by what your server validates — so validate the structure, the required regions and the permitted fields on the backend, every time.

Personalised email is two separate problems: letting a user place a placeholder without knowing the syntax, and resolving that placeholder against real data at send time. The editor solves the first one. Only your application can solve the second.

GrapesJS provides the editing experience. Your backend resolves dynamic data and merge tags when the email is rendered or sent.

Two widths cover almost all of the design review: the width the email is authored at, and a phone. Both are a device switch away in the editor, and neither is the same thing as testing.

An in-editor preview is your browser rendering the canvas markup. A mail client renders a transformed version of that markup through its own engine, and the two can differ. Preview is for design review; a seed list or a rendering service is for compatibility.

Most email disasters are not rendering bugs. They are a broken link, an unfilled merge tag or a missing unsubscribe. All three are cheap to catch on the server, and expensive to catch in an inbox.

Nothing about this architecture asks you to change how you send mail. The editor produces a document; your backend renders it and hands it to whatever provider you already pay for.

GrapesJS is the editor, not your email delivery service.

Neither GrapesJS nor GJS.Market ships an integration with any provider named above, and no partnership is implied. Deliverability, authentication and suppression handling remain your provider's and your application's responsibility.

Not a judgement, a scope check. Every row is something an email builder needs. The left column is work you would own; the right is what GrapesJS gives you before you write a component.

“Available” means the capability ships with the core and needs configuration, not construction. It does not mean it needs no work: every serious email builder defines its own components, restricts its own styles and writes its own storage adapter. Verified against grapesjs 0.23.6 on 2026-09-03.

Real listings from the GJS.Market catalogue, grouped by the stage of the build they belong to. Names, prices and images come straight from the marketplace, so what you see here is what is actually for sale today.

Email foundation

What turns a page editor into an email editor: table-based blocks, an email-shaped Style Manager, import and export.

Browse the category

Newsletter Preset

The newsletter preset: table sections, an email-oriented Style Manager, and a command that inlines CSS on export.

FreeView plugin

MJML Preset

Author with MJML components in the canvas and read the MJML back out for compilation.

FreeView plugin

Blocks users drag

Ready-made email sections, and a way to let users save their own.

Browse the category

GrapesJS Email Blocky – Premium Responsive Email Blocks

A designed set of responsive email blocks, so your first block library is not a blank list.

$69.00View plugin

Users Blocks

Let users save their own arrangements as reusable blocks without touching component code.

$59.00View plugin

Templates

A library of starting points, so nobody begins an email from an empty canvas.

Browse the category

Templates Manager

Template records inside the editor — save, list, load and clone starting points.

$39.00View plugin

The escape hatch

For the one part of an email that has to be hand-written — a tracking pixel, a provider-specific block, a snippet legal supplied.

Browse the category

Grapesjs Component Code Editor

Edit the markup of a single selected component, without opening the whole document.

FreeView plugin

Code Editor

A full HTML and CSS view for the moments when someone needs to see exactly what will be sent.

FreeView plugin

Images and uploads

An asset manager backed by storage that outlives the draft, because a broken image URL is a broken email.

Browse the category

Grapesjs Cloudinary

Back the asset manager with Cloudinary, so email images have a permanent, transformable URL.

FreeView plugin

Grapesjs Uppy

An upload UI in front of the asset manager, with progress, retries and multiple sources.

FreeView plugin

Filestack

Swap the default uploader for Filestack's, including its own picker and transformations.

FreeView plugin

Storage and autosave

Where the project JSON lives, and how often the editor is allowed to write it.

Browse the category

Grapesjs Firebase Storage

Persist project JSON to Firebase without writing a storage adapter first.

FreeView plugin

Directus Storage

Keep email projects in Directus alongside the rest of your content model.

FreeView plugin

Storage Rate Limit

Rate-limit saves so a burst of edits costs one request instead of dozens.

FreeView plugin

Getting the email out

Export the finished document for handoff, review or an existing build pipeline.

Browse the category

Export Zip

FreeView plugin

The shape of the work, in the order it makes sense to do it. Each step links to the guide that covers it properly — this page is a map, not a tutorial.

1. 1

   Initialise the editor

   Mount GrapesJS on a container, set the two devices email needs, and turn off the default local storage before anything else.

   GrapesJS setup guide →
2. 2

   Define email components

   Write the table-based components your emails are made of, restrict what can be styled, and expose each as a block.

   Email components in depth →
3. 3

   Add templates

   Give users somewhere to start. Store templates as project JSON and clone on use rather than editing the original.

   Template systems →
4. 4

   Store projects

   Implement a storage adapter against your API so drafts, autosave and versions are yours to define.

   Storage plugins →
5. 5

   Render and send

   Generate the markup on send, resolve merge tags server-side, and hand the result to your provider.

   Get help with the build →

import grapesjs from 'grapesjs';
import newsletter from 'grapesjs-preset-newsletter';

const editor = grapesjs.init({
  container: '#email-editor',
  height: '100%',
  // Email is authored at a fixed width; give users one extra viewport
  // to check, not a full responsive breakpoint set.
  deviceManager: {
    devices: [
      { id: 'desktop', name: 'Desktop', width: '' },
      { id: 'mobile', name: 'Mobile', width: '375px' },
    ],
  },
  // Curated blocks only: the preset's table sections, plus your own.
  plugins: [
    (ed) => newsletter(ed, { inlineCss: true, showBlocksOnLoad: true }),
  ],
  // Point the editor at your API rather than the browser's localStorage.
  storageManager: {
    type: 'remote',
    autosave: true,
    stepsBeforeSave: 10,
  },
});

// An email-safe button: users edit the label and the link,
// never the table markup that makes it render in Outlook.
editor.DomComponents.addType('email-button', {
  isComponent: (el) => el.dataset?.type === 'email-button',
  model: {
    defaults: {
      draggable: '[data-gjs-type="cell"], td',
      // Users may recolour it; they may not restyle it into a div.
      stylable: ['background-color', 'color', 'border-radius'],
      traits: [
        { name: 'href', label: 'Link' },
        { name: 'label', label: 'Button text' },
      ],
      components: `
        <table role="presentation" cellpadding="0" cellspacing="0">
          <tr><td><a href="#">Read the update</a></td></tr>
        </table>`,
    },
  },
});

Both samples run against grapesjs 0.23.6. `grapesjs-preset-newsletter` and `grapesjs-mjml` are separate BSD-3-Clause packages — the core ships no email preset — so install whichever matches the output format you chose above.

What separates a working demo from an email builder you can hand to customers. Everything here is your work, not the editor's.

An email builder accepts user-authored markup and sends it to third parties. That combination deserves more care than a typical CRUD feature.

• ✕Risk

  Trusting the editor's restrictions

  Locked regions, restricted styles and hidden blocks live in the browser. A crafted request can post any project it likes.

  ✓What to do

  Validate the saved project on the server: required regions present, component types on an allowlist, fields within bounds.

• ✕Risk

  Sending unsanitised custom code

  A code-embed component is a feature request that arrives on every email builder, and it is an injection surface pointed at your customers' inboxes.

  ✓What to do

  Sanitise the stored markup and re-sanitise at render. Restrict who may use a code component, and log every use of it.

• ✕Risk

  Accepting any uploaded file

  Uploads reached from an editor end up on public URLs that live as long as the email does.

  ✓What to do

  Validate type and size on the server, re-encode images, and serve assets from a domain that carries no session cookies.

• ✕Risk

  Leaving the send endpoint under-protected

  Rendering and sending are the expensive, irreversible operations. They are usually protected less carefully than the editor route.

  ✓What to do

  Authorise per template and per recipient list, rate-limit sends, and require a second check before anything goes to a full audience.

• ✕Risk

  Resolving merge tags against whatever is in scope

  A permissive template renderer will happily interpolate a field the sender was never supposed to see.

  ✓What to do

  Resolve against an explicit allowlist of fields for that template, and fail the render on an unknown tag rather than emitting it.

The editor is a large dependency living inside your application. These are the levers that matter, in the order they usually pay off.

• Load the editor lazily

  Import it only on the route that edits an email, and only in the browser. Nothing about the editor belongs in a server render or in your main bundle.

• Lazy-load optional plugins

  A code viewer, an image editor or an MJML compiler can arrive when the user opens that panel rather than at init.

• Keep the block library short

  Every block is markup parsed at startup and a card rendered in the palette. A curated set is faster as well as safer.

• Debounce autosave

  Throttle by change count rather than by keystroke, so a burst of typing produces one request instead of thirty.

• Keep project data lean

  Reference assets by URL. Base64 images inside project JSON make every load, save and version copy heavier.

• Watch custom components

  Component logic that runs on every change is the usual cause of a canvas that feels sluggish on long emails.

No figures are quoted here on purpose: the numbers depend on your block count, your component logic and your users' hardware. Measure the editor route in your own application before and after each change.

Now that the architecture is clear, the trade-off is easy to state. A hosted builder is faster to put in front of a customer; a builder you own is a feature of your product rather than a dependency of it.

Hosted platforms differ substantially from one another, which is why the left column says “depends on the provider” rather than making a blanket claim. Check the specific vendor's terms on data location, retention, customisation limits and what happens to your templates if you leave.

GrapesJS renders into a plain DOM element, so integrating it is a question of which lifecycle hook calls init and which one calls destroy. Your framework powers your application; GrapesJS powers the visual email editing layer.

• ReactMount in an effect, keep the container out of React's render path, and hold the editor instance in a ref.
• VueInit from onMounted and destroy from onUnmounted, with the container as a plain template ref.
• AngularInit from ngAfterViewInit against a ViewChild element, and destroy from ngOnDestroy.
• Next.jsClient-side only. Import dynamically with SSR disabled — the module touches window at import time.