Baue einen Drag-and-Drop-E-Mail-Builder mit GrapesJS

Dies ist ein echter GrapesJS-Editor, der auf dieser Seite läuft – kein Video und kein Screenshot. Ziehen Sie einen Block von rechts hinein, wählen Sie ein beliebiges Element aus, um es neu zu gestalten, wechseln Sie auf Handybreite und lesen Sie dann das erzeugte Markup aus. Header und Footer sind gesperrt – dasselbe Muster, das der Abschnitt weiter unten erklärt.

Ein Drag-and-Drop-E-Mail-Builder ist ein visueller Editor, der es Nutzern ermöglicht, E-Mail-Layouts aus wiederverwendbaren Komponenten zu erstellen, anstatt manuell HTML-Tabellen und E-Mail-spezifische CSS zu schreiben.

Der Unterschied ist, wer die Regeln kennen muss. Ohne Builder muss derjenige, der die E-Mail schreibt, wissen, dass das Layout mit verschachtelten Tabellen gebaut wird, dass die meisten Stile inline stehen müssen und dass ein verirrter Rand das Design in einem einzigen Client zusammenfallen lässt. Mit einem Builder werden diese Regeln einmal – von Ihnen – in Blöcke und Komponenten kodiert, und alle anderen ordnen sie nur noch an.

<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">Yunser Inhalt... </p>
    </td>
  </tr>
</table>

Der Builder ist nicht dafür da, E-Mails einfach zu machen. Er ist dafür da, die schwierigen Teile zur Entscheidung von jemand anderem zu machen – zu Ihrer, einmal getroffen, auf Komponentenebene.

Eine Webseite läuft in einem Browser, mit dem man grob argumentieren kann. Eine E-Mail läuft in dem jeweiligen Client, in dem der Empfänger sie geöffnet hat, und dieser Kunde kann dein Markup umschreiben, deine Stile entfernen oder sie mit einer ganz anderen Engine anlegen. Ein E-Mail-Entwickler muss daher einschränken, was Nutzer produzieren können, nicht nur die Produktion angenehm gestalten.

Du baust keinen Editor, der wunderschöne HTML erzeugt. Du baust einen Editor, der kein gefährliches HTML erzeugen kann.

Das Client-Verhalten ändert sich mit Releases und Rendering-Modi, daher steht auf dieser Seite keine Pro-Client-Supportmatrix. Validiere es mit den Clients und Features, die dein eigenes Publikum tatsächlich nutzt. Zuletzt bewertet 2026-09-03.

GrapesJS kommuniziert nie mit deiner Datenbank und auch nie mit deinem E-Mail-Anbieter. Es gibt dir ein Dokument; alles danach ist deine Architektur.

Drei Eigentümer, keine Überschneidung. Der häufigste architektonische Fehler im Thema dieser Seite ist, dass der Editor etwas in den rechten Spalten tut.

Nichts in den rechten Spalten ist eine Lücke in GrapesJS – diese Zeilen waren nie die Aufgabe des Editors. Sie ab dem ersten Sprint als Anwendungsarbeit zu behandeln, hält die Integration einfach.

Drei Artefakte stammen aus demselben Canvas, und sie sind nicht austauschbar. Eines ist das Projekt, das man behält, zweitens die Lieferformate, die man daraus generiert.

JSON ist das Projekt. HTML und MJML sind die Lieferung. Speichere das erste, generiere die anderen.

Geben Sie den Nutzern keine leere Canvas und einen Div. Liefern Sie eine kleine Auswahl an Komponenten aus, die bereits das Tabellen-Markup, die Inline-Stile und die Rücklagen kodieren, und lassen Sie sie dann anordnen. Diese zehn decken den Großteil ab, was Marketing und Lebenszyklus-E-Mails tatsächlich brauchen.

• Header

  Logo, Markenleiste, Vorkopftext. Meistens gesperrt, sodass jede E-Mail mit derselben Identität abgeschlossen wird.

• Hero

  Überschrift, unterstützende Zeile und eine Aktion. So groß, dass die Nachricht überlebt, ohne dass das Bild geladen wird.

• Text

  Ein Absatzblock mit einem echten Schriftart-Fallback-Stack und Zeilenhöhe, die bei Telefonbreiten Bestand hat.

• Bild

  Feste Breite, explizite Maße und erforderlicher Alternativtext, sodass ein blockiertes Bild weiterhin eine lesbare E-Mail hinterlässt.

• Button

  Ein tabellenbasierter Button statt eines gestalteten Ankers – der Unterschied ist bei strengeren Clients sichtbar.

• Zwei-Spalten-Abschnitt

  Eine Tabellenzeile, die auf schmalen Viewports gestapelt wird — die Reihenfolge der Stapelung legen Sie vorher fest.

• Produktkarte

  Bild, Name, Preis und Link, gesteuert von Feldern, die dein Backend ausfüllt, statt per Kopieren und Einfügen.

• Social-Links

  Eine feste Reihe von Symbolen und URLs, die als Einstellungen und nicht als Markup bearbeitet werden kann.

• Trennlinie

  Eine Linie, die mit einem Tabellenrahmen statt mit einem <hr>-Element gezeichnet wird — mehrere E-Mail-Clients stylen <hr> um.

• Footer

  Absenderidentität, Adresse und Link zum Abmelden. Normalerweise gesperrt, da dies Verpflichtungen sind.

Eine Komponente ist die Definition; ein Block ist, wie ein Nutzer einen auf das Canvas bringt. Die Blockbibliothek ist der stärkste Hebel, den man über das haben kann, was Menschen bauen können – und der einfachste, um durch Großzügigkeit falsch zu liegen.

Das Sperren in GrapesJS ist kein Modus oder eine Planstufe – es ist eine Menge von Optionen auf einer Komponentendefinition. Ein gesperrter Bereich rendert weiterhin, exportiert weiterhin und weigert sich einfach, im Editor gezogen, gelöscht oder neu gestaltet zu werden.

Diese Optionen steuern den Editor UI. Sie sind keine Autorisierung. Ein modifiziertes Projekt, das direkt an deinem Speicherpunkt gepostet wird, ist nur durch das begrenzt, was dein Server validiert – also validiere jedes Mal die Struktur, die erforderlichen Regionen und die erlaubten Felder im Backend.

Personalisierte E-Mails bestehen aus zwei getrennten Problemen: einem Nutzer zu erlauben, einen Platzhalter zu platzieren, ohne die Syntax zu kennen, und diesen Platzhalter mit echten Daten zum Zeitpunkt des Senden zu lösen. Der Editor löst das erste. Nur deine Anwendung kann das zweite lösen.

GrapesJS bietet das Bearbeitungserlebnis. Ihr Backend löst dynamische Daten und Merge Tags auf, wenn die E-Mail gerendert oder gesendet wird.

Zwei Breiten decken fast die gesamte Designprüfung ab: die Breite, in der die E-Mail verfasst ist, und ein Telefon. Beide sind im Editor nur ein Geräteschalter entfernt, und keines ist dasselbe wie das Testen.

Eine In-Editor-Vorschau ist dein Browser, der das Canvas-Markup rendert. Ein Mail-Client rendert eine transformierte Version dieses Markups über seine eigene Engine, und die beiden können unterschiedlich sein. Preview dient der Designprüfung; eine Seed-Liste oder ein Rendering-Service dient der Kompatibilität.

Die meisten E-Mail-Katastrophen sind keine Fehler. Sie sind ein defekter Link, ein unbefülltes Merge-Tag oder ein fehlendes Abmelden. Alle drei sind auf dem Server günstig zu entdecken und teuer im Posteingang.

Nichts an dieser Architektur verlangt von dir, die Art und Weise zu ändern, wie du Post versendest. Der Editor erstellt ein Dokument; dein Backend rendert es und übergibt es an den Anbieter, für den du bereits bezahlst.

GrapesJS ist der Editor, nicht dein E-Mail-Zustelldienst.

Weder GrapesJS noch GJS.Market liefern eine Integration mit einem der oben genannten Anbieter aus, und es wird keine Partnerschaft impliziert. Die Lieferung von Authentifizierung, Authentifizierung und Unterdrückung bleiben in der Verantwortung Ihres Anbieters und Ihrer Anwendung.

Kein Urteil, sondern ein Scope-Check. Jede Zeile ist etwas, das ein E-Mail-Builder braucht. Die linke Spalte zeigt Arbeiten, die du besitzen würdest; die rechte ist das, was GrapesJS dir gibt, bevor du eine Komponente schreibst.

"Verfügbar" heißt, dass die Fähigkeit im Kern enthalten ist und konfiguriert, nicht gebaut werden muss. Es heißt nicht, dass keine Arbeit anfällt: Jeder ernsthafte E-Mail-Builder definiert eigene Komponenten, beschränkt die eigenen Stile und schreibt seinen eigenen Storage-Adapter. Geprüft gegen grapesjs 0.23.6 am 2026-09-03.

Echte Einträge aus dem GJS.Market-Katalog, gruppiert nach der Bauphase, zu der sie gehören. Namen, Preise und Bilder stammen direkt vom Marktplatz, daher sehen Sie hier das, was heute tatsächlich zum Verkauf steht.

E-Mail-Grundlage

Was einen Seiteneditor in einen E-Mail-Editor verwandelt: tabellenbasierte Blöcke, ein E-Mail-förmiges Style Manager, Import und Export.

Durchstöbern Sie die Kategorie

Newsletter Preset

Das Newsletter-Preset: Tabellenabschnitte, ein E-Mail-orientiertes Style Manager und ein Befehl, der CSS beim Export inlineiert.

KostenlosPlugin ansehen

MJML Preset

Autor mit MJML-Komponenten im Canvas und lese das MJML für die Zusammenstellung wieder aus.

KostenlosPlugin ansehen

Blöcke, die Nutzer ziehen

Fertige E-Mail-Bereiche und eine Möglichkeit, dass Nutzer ihre eigenen speichern können.

Durchstöbern Sie die Kategorie

GrapesJS Email Blocky – Premium Responsive Email Blocks

Eine entworfene Reihe von responsiven E-Mail-Blöcken, damit Ihre erste Blockbibliothek keine leere Liste ist.

69,00 $Plugin ansehen

Users Blocks

Erlauben Sie Benutzern, ihre eigenen Arrangements als wiederverwendbare Blöcke zu speichern, ohne den Komponentencode zu berühren.

59,00 $Plugin ansehen

Vorlagen

Eine Bibliothek von Startpunkten, sodass niemand eine E-Mail von einer leeren Canvas startet.

Durchstöbern Sie die Kategorie

Templates Manager

Vorlagenaufzeichnungen im Editor – Speichere, Liste auf, laden und Klonen Startpunkte.

39,00 $Plugin ansehen

Die Fluchtluke

Für den einen Teil einer E-Mail, der handschriftlich sein muss – ein Tracking-Pixel, ein anbieterspezifischer Block, ein legaler Ausschnitt.

Durchstöbern Sie die Kategorie

Grapesjs Component Code Editor

Bearbeiten Sie das Markup einer einzelnen ausgewählten Komponente, ohne das ganze Dokument zu öffnen.

KostenlosPlugin ansehen

Code Editor

Eine vollständige HTML- und CSS-Ansicht für die Momente, in denen jemand genau sehen muss, was gesendet wird.

KostenlosPlugin ansehen

Bilder und Uploads

Ein Vermögensverwalter, der durch Speicher unterstützt wird, der den Entwurf überdauert, denn eine fehlerhafte Bild-URL ist eine defekte E-Mail.

Durchstöbern Sie die Kategorie

Grapesjs Cloudinary

Unterstützt den Asset Manager mit Cloudinary, damit E-Mail-Bilder eine dauerhafte, transformierbare URL haben.

KostenlosPlugin ansehen

Grapesjs Uppy

Ein Upload von UI vor dem Asset Manager, mit Fortschritten, erneuten Versuchen und mehreren Quellen.

KostenlosPlugin ansehen

Filestack

Tausche den Standard-Uploader gegen Filestack, inklusive eigenem Picker und Transformationen.

KostenlosPlugin ansehen

Speicher und autosave

Wo sich das Projekt JSON befindet und wie oft der Editor es schreiben darf.

Durchstöbern Sie die Kategorie

Grapesjs Firebase Storage

Persistiere Projekt JSON auf Firebase, ohne vorher einen Speicheradapter zu schreiben.

KostenlosPlugin ansehen

Directus Storage

Behalten Sie E-Mail-Projekte in Directus zusammen mit dem Rest Ihres Inhaltsmodells.

KostenlosPlugin ansehen

Storage Rate Limit

Rate-Limit speichert, sodass ein Burst von Bearbeitungen eine Anfrage statt Dutzende kostet.

KostenlosPlugin ansehen

Die E-Mail verbreiten

Exportiere das fertige Dokument für die Übergabe, Überprüfung oder eine bestehende Build-Pipeline.

Durchstöbern Sie die Kategorie

Export Zip

KostenlosPlugin ansehen

Die Form des Werks, in der Reihenfolge, in der es sinnvoll ist. Jeder Schritt führt zu dem Leitfaden, der es richtig behandelt – diese Seite ist eine Karte, kein Tutorial.

1. 1

   Initialisieren Sie den Editor

   Mounte GrapesJS auf einem Container, setze die E-Mail-Anforderungen der beiden Geräte und schalte den Standardspeicher vor allem anderen aus.

   GrapesJS-Einrichtungsanleitung →
2. 2

   Definiere E-Mail-Komponenten

   Schreiben Sie die tabellenbasierten Komponenten, aus denen Ihre E-Mails bestehen, beschränken, was gestylt werden kann, und stellen Sie jede als Block bereit.

   E-Mail-Komponenten in der Tiefe →
3. 3

   Vorlagen hinzufügen

   Gib den Nutzern einen Anfangspunkt. Speichere Vorlagen als Projekt JSON und klone sie bei Gebrauch, anstatt das Original zu bearbeiten.

   Template-Systeme →
4. 4

   Projekte speichern

   Implementiere einen Speicheradapter an deinem API, damit Entwürfe, autosave und Versionen von dir definiert werden können.

   Speicher-Plugins →
5. 5

   Rendern und senden

   Generiere das Markup beim Senden, löse Merge-Tags serverseitig auf und übergebe das Ergebnis deinem Anbieter.

   Hol dir Hilfe beim Bau →

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>`,
    },
  },
});

Beide Samples laufen gegen grapesjs 0.23.6. 'grapesjs-preset-newsletter' und 'grapesjs-mjml' sind separate BSD-3-Clause-Pakete – der Kern wird ohne E-Mail-Preset ausgeliefert – also installieren Sie das Format, das dem oben gewählten Ausgabeformat entspricht.

Was unterscheidet eine funktionierende Demo von einem E-Mail-Builder, den man den Kunden geben kann? Alles hier ist deine Arbeit, nicht die des Editors.

Ein E-Mail-Builder akzeptiert von Nutzern erstelltes Markup und sendet es an Dritte. Diese Kombination verdient mehr Sorgfalt als eine typische CRUD-Funktion.

• ✕Risiko

  Vertrauen in die Einschränkungen des Editors

  Gesperrte Regionen, eingeschränkte Stile und versteckte Blöcke befinden sich im Browser. Eine erstellte Anfrage kann jedes beliebige Projekt posten.

  ✓Was zu tun ist

  Validiere das gespeicherte Projekt auf dem Server: erforderliche Regionen vorhanden, Komponententypen auf einer Zulassungsliste, Felder innerhalb der Grenzen.

• ✕Risiko

  Senden von unbeschönigtem benutzerdefiniertem Code

  Eine Code-Embed-Komponente ist eine Feature-Anfrage, die auf jedem E-Mail-Builder ankommt und eine Injektionsfläche ist, die auf die Posteingänge Ihrer Kunden zeigt.

  ✓Was zu tun ist

  Desinfizieren Sie das gespeicherte Markup und desinfizieren Sie es beim Rendern erneut. Beschränken, wer eine Codekomponente verwenden darf, und protokollieren Sie jede Nutzung davon.

• ✕Risiko

  Akzeptiert jede hochgeladene Datei

  Uploads, die von einem Editor erreicht werden, landen auf öffentlichen URLs, die so lange bestehen wie die E-Mail.

  ✓Was zu tun ist

  Typ und Größe auf dem Server validieren, Bilder neu kodieren und Assets von einer Domain bereitstellen, die keine Session-Cookies enthält.

• ✕Risiko

  Das Senden-Endpunkt untergeschützt

  Das Rendern und Senden sind die teuren, irreversiblen Operationen. Sie werden in der Regel weniger sorgfältig geschützt als der Editor-Weg.

  ✓Was zu tun ist

  Autorisieren Sie pro Vorlage und pro Empfängerliste, Versand von Zinsbegrenzungen und eine zweite Kontrolle, bevor etwas an ein volles Publikum geht.

• ✕Risiko

  Auflösen von Merge-Tags gegen das, was im Anwendungsbereich liegt,

  Ein permissiver Template-Renderer interpoliert gerne ein Feld, das der Sender eigentlich nie sehen sollte.

  ✓Was zu tun ist

  Resolve gegen eine explizite Erlaubnisliste von Feldern für diese Vorlage und das Rendern bei einem unbekannten Tag fehlschlagen, anstatt es auszusenden.

Der Editor ist eine große Abhängigkeit, die in deiner Anwendung lebt. Das sind die Hebel, die zählen, in der Reihenfolge, in der sie sich normalerweise auszahlen.

• Lade den Editor träge

  Importiere es nur auf der Route, die eine E-Mail bearbeitet, und nur im Browser. Nichts am Editor gehört in ein Server-Rendering oder in dein Hauptbundle.

• Lazy-Load-optionale Plugins

  Ein Code-Viewer, ein Bildeditor oder ein MJML-Compiler können erscheinen, wenn der Benutzer dieses Panel öffnet, anstatt auf init.

• Halte die Blockbibliothek kurz

  Jeder Block wird beim Start mit Markup geparst und eine Karte in der Palette gerendert. Ein kuratiertes Set ist schneller und sicherer.

• Debounce autosave

  Drosseln Sie nach Änderungsanzahl statt nach Tastendrücken, sodass ein Tippstoß eine Anfrage statt dreißig erzeugt.

• Halte die Projektdaten schlank

  Referenziere Assets nach URL. Base64-Bilder im Projekt JSON machen jede Lade-, Speicher- und Versionskopie schwerer.

• Achten Sie auf eigene Komponenten

  Komponentenlogik, die bei jeder Änderung läuft, ist die übliche Ursache für eine Canvas, die sich bei langen E-Mails träge anfühlt.

Absichtlich werden hier keine Zahlen genannt: Die Zahlen hängen von Ihrer Blockanzahl, Ihrer Komponentenlogik und der Hardware Ihrer Nutzer ab. Messen Sie den Editor-Weg in Ihrer eigenen Anwendung vor und nach jeder Änderung.

Jetzt, da die Architektur klar ist, lässt sich der Kompromiss leicht benennen. Ein gehosteter Builder ist schneller vor einen Kunden zu stellen; ein Builder, den Sie besitzen, ist ein Merkmal Ihres Produkts und nicht eine Abhängigkeit davon.

Gehostete Plattformen unterscheiden sich erheblich voneinander, weshalb in der linken Spalte steht: "Hängt vom Anbieter ab" statt eine pauschale Aussage zu treffen. Überprüfen Sie die Bedingungen des jeweiligen Anbieters bezüglich Datenstandort, Speicherhaltung, Anpassungsgrenzen und was mit Ihren Vorlagen passiert, wenn Sie gehen.

GrapesJS rendert in ein einfaches DOM-Element, daher ist die Integration eine Frage, welcher Lebenszyklus-Hook init aufruft und welcher destroy. Dein Framework treibt deine Anwendung an; GrapesJS steuert die visuelle E-Mail-Bearbeitungsebene.

• ReactMounte einen Effekt ein, halte den Container außerhalb des Renderpfads von React und halte die Editor-Instanz in einer Referenz.
• VueInit aus onMounted und destroy aus onUnmounted, mit dem Container als einfacher Vorlagenreferenz.
• AngularInit aus ngAfterViewInit gegen ein ViewChild-Element und destroy aus ngOnDestroy.
• Next.jsNur auf der Clientseite. Dynamisch importieren mit deaktiviertem SSR – das Modul berührt das Fenster zur Importzeit.