Build an Email Template Builder with GrapesJS

Open a template off the shelf, change it, then save it as a new one. The shelf grows by one. That loop — not the individual designs — is what an email template builder gives your users.

The MJML editor demo published by the GrapesJS project itself. Add a section, edit the copy, then look at the generated markup.

An email template builder lets people create and change email layouts visually instead of hand-writing HTML email markup. A template *library* ships finished designs; a template *builder* ships the ability to make them — and to keep making them after you have shipped.

Templates give your users a starting point. A builder gives them control.

A library is a shelf with a ceiling: it covers what it was built to cover, and requests above that line have nowhere to go. A builder is a loop — and the shelf grows every time someone goes round it.

• "We need a clean welcome email by Friday."

  Covered✓

  Template library

  Solved. This is exactly what a good library is for — pick one, change the words, send.

  Covered✓

  Template builder

  Also solved, from the same starting points. A builder ships with a library inside it.

• "Every tenant needs their own legal footer."

  Not covered–

  Template library

  One shared footer, or a fork of every template per tenant.

  Covered✓

  Template builder

  One footer block, saved once per tenant and reused across their templates.

• "Put the customer's actual order in the receipt."

  Not covered–

  Template library

  Static placeholder text. The data has to be spliced in downstream.

  Covered✓

  Template builder

  A component bound to your order model, editable as a block and resolved at send time.

• "Restore the version we sent last Tuesday."

  Not covered–

  Template library

  Whatever the file was overwritten with is what you have.

  Covered✓

  Template builder

  A version row. Restoring is a query, not an archaeology project.

• "Let our customers build their own, without emailing us."

  Not covered–

  Template library

  Not what a library does — it has no authoring surface.

  Covered✓

  Template builder

  The whole point. Your users create and keep templates you never see.

Ship the library. Then ship the thing that makes more of them.

The editing surface your users get, and the parts of it you control.

Give users a library of sections to assemble from, instead of making them start every email from an empty canvas. Each one is a block definition you register once.

• Header

  Logo, preheader text and the navigation row, if you use one.

• Hero

  The opening statement and the first call to action.

• Product grid

  A row or grid of items, bound to your catalogue where you want it live.

• Feature list

  Short icon-and-text rows for release notes and onboarding.

• Pricing

  Plan comparison laid out to survive a table-based renderer.

• Testimonial

  A quote, an attribution and an optional avatar.

• Call to action

  A bulletproof button that renders without background images.

• Footer

  Address, preferences link and the unsubscribe link you are legally required to include.

Standard blocks cover layout. What makes the builder yours is the components that know about your data — an order, a subscription, a booking, a recommendation.

1. Standard
2. ↓Composed
3. ↓Bound
4. ↓Your data model

The editor renders a placeholder while the template is being written. Your backend swaps in the real values at send time.

In a template system, templates differ by who owns them and who may change them — not only by what they say. These are the classes worth modelling from day one.

These are ownership classes in a template system, not products for sale. GJS.Market lists editor plugins and presets; it does not sell email templates.

Preview the layout at the widths email actually renders at, while you are still editing it. 600px is the long-standing convention for the body column — a convention, not a specification.

Two columns on a desktop client, stacked on a phone — decided in the template, not by the recipient's client guessing.

Email clients implement HTML and CSS differently, and always have. A visual builder does not remove that — it standardises the authoring step so the same known-good markup comes out every time.

Constraints as verified on 2026-08-28. Behaviour changes; check caniemail.com for the current state, and test production emails against the clients your own audience actually uses.

mjml exists to make responsive email markup something you generate rather than hand-maintain. GrapesJS can be extended with grapesjs-mjml to put a visual editing surface on top of it.

The question that decides whether you have a builder or a viewer: what rows exist after a user clicks Save? Three tables cover it.

The editor is a client. It asks your API for a template and hands one back; it never learns who your tenants are, and it never holds the only copy of anything.

// Storage scoped to the tenant AND the template. The editor never learns who
// the tenant is — your API does, from the session, and refuses everything else.
editor.Storage.add('remote', {
  async load({ templateId }) {
    const res = await fetch(`/api/templates/${templateId}/project`);
    return res.json();
  },
  async store(project, { templateId }) {
    await fetch(`/api/templates/${templateId}/project`, {
      method: 'PUT',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify(project),
    });
  },
});

Integrate the editor with the backend you already run, rather than moving your email workflow onto someone else's platform. GJS.Market sells editor plugins — it does not host your templates and does not send your email.

The moment a second customer saves a template, ownership stops being a detail. Three tiers cover almost every product.

The same template system, pointed at different jobs.

The editing canvas is the visible part. A template system is the rest of it — and the rest is where the time goes.

What a template system is made of

• Editor canvas
• Drag and drop
• Block registry
• Component model
• Style controls
• Responsive preview
• Asset management
• Template CRUD
• Versioning and restore
• Merge-tag validation
• Tenant scoping
• Undo and redo
• HTML export
• MJML compilation
• Ongoing client testing

GrapesJS gives you the editing layer. The template system on top of it — ownership, versioning, tenancy — is yours, and should be: it is the part that matches your product.

Real listings from the catalogue, grouped by the job they do inside a template system. Names and prices come straight from the marketplace, so nothing here can drift from what is actually for sale.

The library itself

Saving, listing and reopening templates — the subject of this page.

Browse this category

Templates

Templates Manager

Adds the save, list and reopen surface a template library needs, so users are not managing templates in a spreadsheet.

$39.00View plugin

Starting points

What a new template begins as, before anyone has saved one.

Browse this category

Preset

MJML Preset

Brings MJML components into the editor, compiled live, so responsive markup is generated rather than hand-written.

FreeView plugin

Preset

Newsletter Preset

The pre-MJML path: table-based email blocks and a CSS inliner, with no compile step in between.

FreeView plugin

Blocks

The sections a template is assembled and re-assembled from.

Browse this category

Blocks

GrapesJS Email Blocky – Premium Responsive Email Blocks

A large set of email-safe blocks, so your users start from real sections instead of an empty column.

$69.00View plugin

The escape hatch

For the part of a template that has to be hand-written.

Browse this category

Code

Grapesjs Component Code Editor

Lets a developer edit the HTML and CSS of one selected component, without opening the whole template.

FreeView plugin

Where templates live

Wiring the editor's storage to a backend you control.

Browse this category

Storage

Grapesjs Firebase Storage

Persists project data to Firebase, keyed however your app keys its templates.

FreeView plugin

Storage

Directus Storage

Persists project data to Directus, which is convenient when templates live beside your other content.

FreeView plugin

Assets

The images a template references, which must outlive the template.

Browse this category

Assets

Grapesjs Cloudinary

Points the asset manager at Cloudinary, so template images are transformed and served from one place.

FreeView plugin

Uploads

Grapesjs Uppy

Adds a fuller upload flow for the images your users drop into a template.

FreeView plugin

Handoff

Getting a finished template out of the system.

Browse this category

Export

Export Zip

Packages the rendered output for handoff to a system that expects files rather than an API call.

FreeView plugin

Four combinations that already work together, chosen by whose template library you are building.

Prices are read live from the catalogue at build time.

GrapesJS is the editing layer and stops at the HTML. Everything after that is your backend and the provider you already pay — there is no sending built into the editor, and none implied here.

The editor core plus the official MJML plugin. Both are BSD-3-Clause.

import grapesjs from 'grapesjs';
import grapesjsMjml from 'grapesjs-mjml';
import 'grapesjs/dist/css/grapes.min.css';

// One editor instance per template being edited. The template id — not a page
// id — is what every load and store call is keyed by.
const editor = grapesjs.init({
  container: '#template-editor',
  plugins: [grapesjsMjml],
  pluginsOpts: {
    [grapesjsMjml]: {
      imagePlaceholderSrc: 'https://cdn.your-app.com/email/placeholder.png',
    },
  },
  storageManager: {
    type: 'remote',
    autosave: true,
    stepsBeforeSave: 10,
  },
});

// "Save as new template" — a row your customer owns from now on.
async function saveAsTemplate(name) {
  const res = await fetch('/api/templates', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      name,
      project: editor.getProjectData(), // re-openable in the editor
    }),
  });
  return res.json(); // { id, name, version: 1 }
}

// Editing an existing template appends a version rather than overwriting it,
// so "restore the version we sent last Tuesday" stays a query, not a restore.
async function saveVersion(templateId) {
  await fetch(`/api/templates/${templateId}/versions`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ project: editor.getProjectData() }),
  });
}

1. Install the core and the MJML plugin
2. →Mount the editor, keyed by template id
3. →Register your blocks and bound components
4. →Wire storage to your own API
5. →Add save-as-template and versioning
6. →Hand the rendered HTML to your provider

Framework specifics live on their own pages — this page stays framework-neutral on purpose.

Teams that need email creation to happen inside their product rather than beside it.

This page is about the template system. These cover the neighbouring questions.

Start with GrapesJS, shape the editing experience around your product, and extend it with the plugins your template system needs.

Related reading