Build a React Email Builder with GrapesJS

Not a hosted editor you rent, and not a template gallery. An editing layer you mount inside the application you already run.

This canvas is a React component running on this page — no editor bundle, no iframe. Add a block, click any section to select it, retype the text in place, restyle it, reorder it, and switch the preview between desktop, tablet and mobile. Open the HTML tab to see the kind of markup an email builder hands back to your code.

The newsletter preset: email-safe blocks, a restricted style manager and table-based output. This is the closest thing to what your users would see.

A React email builder is a visual editor that runs inside a React application and lets users create and customise email templates without writing HTML email markup by hand. It is not a separate product your users log into: it is a component in your app, so the templates, the accounts that own them and the infrastructure that sends them all stay on your side.

The editor's job ends at producing markup. Everything before and after it is your application.

In every one of these, the alternative is a developer editing a template by hand each time someone in the business wants a change.

It is the editing foundation, not the finished product. That distinction is the point: everything below is a hook you build on rather than a feature you accept as given.

GrapesJS provides the visual editing layer. Your React application stays in control of users, data, storage and publishing — which is the whole argument for embedding an editor rather than sending people to someone else's.

Embedding an editor into someone else's product raises a different set of questions.

Both paths end in the same place. The only real difference is where the module is allowed to be evaluated.

Three packages and a component. Everything after this — storage, custom blocks, MJML — is covered further down the page.

import GjsEditor from '@grapesjs/react';
import newsletter from 'grapesjs-preset-newsletter';
import 'grapesjs/dist/css/grapes.min.css';

// A normal React component. The editor is a child of your tree, so your
// router, your auth context and your providers all still wrap it.
export default function EmailBuilder({ template, onSave }) {
  return (
    <GjsEditor
      options={{
        height: '100vh',
        // Storage is wired to your own API further down this page.
        storageManager: false,
        plugins: [newsletter],
        projectData: template,
      }}
      onEditor={(editor) => {
        // Everything the user builds comes back out as plain data you can
        // put straight into React state or POST to your backend.
        editor.on('update', () => {
          onSave({
            html: editor.getHtml(),
            css: editor.getCss(),
            project: editor.getProjectData(),
          });
        });
      }}
    />
  );
}

// app/emails/page.tsx  (or pages/emails.tsx)
import dynamic from 'next/dynamic';

// GrapesJS reaches for window/document as it initialises, so it can only run
// in the browser. In Next.js that means one dynamic import with ssr: false —
// this is the whole of the Next.js-specific work.
const EmailBuilder = dynamic(() => import('@/components/EmailBuilder'), {
  ssr: false,
  loading: () => <EditorSkeleton />,
});

export default function EmailsPage({ template }) {
  return <EmailBuilder template={template} onSave={saveTemplate} />;
}

1. Initialise the editor inside a React component
2. →Add an email preset so the blocks and styles are email-safe
3. →Register the blocks your product needs
4. →Configure storage against your own API
5. →Export HTML, or compile MJML on the server
6. →Hand the result to your sending provider

Versions above were checked against the published packages on 2026-09-03: grapesjs 0.23.6 is BSD-3-Clause; @grapesjs/react is MIT.

These come from the editor core and its email presets, not from anything you have to write.

MJML exists to make responsive email markup writable by hand. A visual builder on top of it means nobody has to. GrapesJS does not include MJML in its core — a plugin adds MJML components to the editor, so the project serialises to MJML rather than to plain HTML.

// pages/api/email/compile.ts
//
// mjml is a Node package — it parses and renders on the server, not in the
// browser. So the editor produces MJML in the client and this route turns it
// into the table-based HTML that email clients actually accept.
import mjml2html from 'mjml';

export default function handler(req, res) {
  const { html, errors } = mjml2html(req.body.mjml, {
    validationLevel: 'soft',
    keepComments: false,
  });

  // MJML reports what it could not understand rather than failing silently.
  if (errors.length) console.warn('[mjml]', errors);

  res.status(200).json({ html });
}

The compiler is a Node package, so compilation belongs on the server — in Next.js, an ordinary API route. The reverse direction is not symmetrical: arbitrary HTML does not convert cleanly back into MJML, so pick the format your workflow needs before you build on one.

The editor hands your code three different things, and a React application usually wants all three at different moments.

This is where an embedded builder pulls ahead of a generic email tool: the blocks can know about your domain. A block is not a picture of a product card — it can look the product up.

To be precise about what this is: an arbitrary React component is not converted into an email component. JSX renders a DOM tree, and email clients will not honour most of it. What you write is a GrapesJS component type whose toHTML emits email-safe markup and whose traits map onto a record your application owns. The wiring is yours; the editor supplies the place to put it.

Reduce repetitive design work by shipping the sections your product actually sends, rather than a generic set your users have to adapt every time.

A template is just a saved project document, so shipping a starter library means seeding rows and loading one as projectData when a user picks it. These are the categories most products end up needing:

These are layout categories, not products for sale. GJS.Market lists email presets, block packs and template managers — it does not sell ready-made email designs, and this page will not show you cards for products that do not exist.

Users switch device width while editing, and the canvas re-lays out at that width. Email widths are narrower than web ones: 600px has been the safe desktop maximum for years.

A preview is a preview. It shows how the markup reflows, not how a specific client will render it — which is the next section.

Email clients implement HTML and CSS differently, and have done for twenty years. A visual builder standardises the authoring workflow; it does not make the clients agree with each other.

Connect the editor to the backend and data model you already have. Your users, your authentication, your database, your permissions and your publishing workflow all stay exactly where they are.

// The editor asks your API for a template and hands it back on save.
// Your users, your auth, your database, your permissions — unchanged.
const options = {
  storageManager: {
    type: 'remote',
    autosave: true,
    stepsBeforeSave: 5,
    options: {
      remote: {
        urlStore: `/api/email-templates/${templateId}`,
        urlLoad: `/api/email-templates/${templateId}`,
        // Your existing session cookie is all the auth it needs.
        fetchOptions: { credentials: 'include' },
      },
    },
  },
};

// pages/api/email-templates/[id].ts — an ordinary Next.js route handler.
export default async function handler(req, res) {
  const session = await getSession(req);
  if (!session) return res.status(401).end();

  if (req.method === 'POST') {
    await db.emailTemplate.update({
      where: { id: req.query.id, orgId: session.orgId },
      data: { project: req.body },
    });
    return res.status(200).json({ ok: true });
  }

  const row = await db.emailTemplate.findFirst({
    where: { id: req.query.id, orgId: session.orgId },
  });
  return res.status(200).json(row?.project ?? {});
}

GJS.Market does not host your templates, store your data or send your email. It sells plugins for an editor you run yourself.

Customise the editing experience until it reads as a native part of your React application rather than a third-party panel bolted into it. There is no vendor branding to remove in the first place.

What you can change

• Toolbar and buttons
• Panels and their layout
• Block palette and categories
• Component types and traits
• Style manager sectors
• Commands and keyboard shortcuts
• The surrounding React UI

The most thorough version is to run the editor headless and build the entire interface in React yourself, using the editor only for the canvas and the model.

It is a reasonable thing to consider, right up until the list of parts is written down. Every item below is something an email editor needs before it is usable — not a nice-to-have.

What an email editor is made of

• Editing canvas
• Selection and hit testing
• Drag and drop
• Component model
• Block system
• Style manager
• Responsive controls
• Asset manager
• Template storage
• Undo / redo history
• Serialisation
• HTML export
• MJML integration
• Preview
• Ongoing maintenance

Build your email product — not another editor from scratch. We are not going to put a number of saved months on that; how long it would take your team depends on your team.

Every listing below is a real product with a live page, and its name, price and thumbnail render straight from the catalogue — so nothing on this page can drift out of sync with what is actually for sale.

React UI

The layer this page is about: React interfaces built around the editor core, for teams who want the surrounding UI to be React rather than the stock panels.

Browse this category

React UI

React UI for GrapesJS

A React interface around the editor, for teams who would rather extend components than configure panels.

FreeView plugin

React preset

Reactor Preset for GrapesJS

A React-oriented preset, useful as a starting point when the surrounding application is already React.

FreeView plugin

React shell

GrapesJS Shadcn

A complete React interface built on a familiar component library, for products that want the editor to match the rest of their UI.

$999.99View plugin

Email presets

Replace the default web blocks with email-safe ones and narrow the style manager to properties email clients honour. This is what makes the editor an email editor.

Browse this category

MJML

MJML Preset

Adds MJML components to the editor so the project serialises to MJML and compiles to responsive HTML on your server.

FreeView plugin

Email preset

Newsletter Preset

The email starting point: email-safe blocks, a narrowed style manager and table-based output.

FreeView plugin

Email preset

Whitener Preset GrapesJS

An alternative email preset, worth comparing against the newsletter one before you commit to a block vocabulary.

FreeView plugin

Blocks and templates

Ready-made sections and a manager for saving and reloading templates, so your users are not assembling every email from primitives.

Browse this category

Email blocks

GrapesJS Email Blocky – Premium Responsive Email Blocks

A larger set of ready email sections, so your users assemble from finished pieces rather than from primitives.

$69.00View plugin

Templates

Templates Manager

Save, list and reload projects — the mechanics behind shipping a starter template library to your users.

$39.00View plugin

Code access

For the moments a developer needs to see or hand-edit the markup a section produces.

Browse this category

Code

Grapesjs Component Code Editor

Shows the markup a selected component produces, for the moments a developer needs to see or edit it directly.

FreeView plugin

Storage adapters

Wire the storage manager to a backend without writing the adapter, if the one you use is already covered.

Browse this category

Storage

Grapesjs Firebase Storage

Persists projects to Firebase without writing a storage adapter yourself.

FreeView plugin

Storage

Directus Storage

Persists projects to a Directus backend, if that is already where your content lives.

FreeView plugin

Assets

Image upload and media management, pointed at services teams already run rather than at local files.

Browse this category

Assets

Grapesjs Cloudinary

Points the asset manager at Cloudinary, so email images come from a service that can transform and serve them.

FreeView plugin

Uploads

Grapesjs Uppy

A fuller upload experience in the asset manager, including sources beyond the local file picker.

FreeView plugin

Export

Getting the finished markup out of the editor and into whatever comes next in your pipeline.

Browse this category

Export

Export Zip

Packages the generated markup and assets for handing to whatever comes next in your pipeline.

FreeView plugin

Four combinations that map onto real requirements. Every listing shown is one that exists — there is no imaginary plugin filling a gap in a diagram.

Prices come from the catalogue at build time.

The pattern repeats across products that otherwise have nothing in common.

The editor creates the email. Your infrastructure sends it. Keeping that line clear is what makes the rest of this architecture simple.

Examples of providers teams hand it to

• Amazon SES
• SendGrid
• Mailgun
• Postmark

Named as examples of where the markup ends up, not as built-in integrations. Neither GrapesJS nor GJS.Market ships a connector for any of them; you call their SDK from your own backend, as you already do for the rest of your email.

This is an architectural trade-off, not a scoreboard. The right-hand column says "depends" honestly: hosted editors differ from each other and change their terms, and we are not going to invent a specific answer on their behalf.

GrapesJS column verified against grapesjs 0.23.6 and @grapesjs/react on 2026-09-03. For a comparison against a specific named vendor, with its published pricing, see the dedicated page.

Neighbouring pages that take the same editor in a different direction.

Start with GrapesJS, integrate it into your React application, and extend the editor with the email plugins your product actually requires.