GrapesJS Angular: Build a Visual Editor with Angular

The stock GrapesJS build — the editor you get from `grapesjs.init()` with the standard preset, before any plugin is added. Drag a block from the right panel, select it, and edit its typography and spacing in the style manager.

GrapesJS is the visual editing engine. Angular is the application framework. Almost every integration problem people hit comes from expecting one of them to do the other's job, so it is worth being explicit about the line between them.

Angular is your application. GrapesJS is your visual editing engine.

One dependency and one stylesheet. GrapesJS ships its own CSS, and without it the editor mounts but renders as unstyled markup — which is the single most common reason a first integration looks broken.

1 — Add the dependency

2 — Register the stylesheet

// angular.json → projects.<app>.architect.build.options
{
  "styles": [
    "src/styles.css",
    "node_modules/grapesjs/dist/css/grapes.min.css"
  ]
}

Registering the stylesheet in angular.json applies it globally. If the editor lives on one lazy-loaded route and you would rather not pay for the CSS everywhere, import it inside the editor component's own stylesheet instead.

Before you write the component

Three files, nothing generated, nothing hidden. Copy them into an Angular application and you have a working visual editor on a route. Everything later on this page — storage, assets, custom components, plugins — is an addition to this component, not a rewrite of it.

// editor.component.ts
import {
  AfterViewInit,
  Component,
  ElementRef,
  OnDestroy,
  ViewChild,
} from '@angular/core';
import grapesjs, { type Editor } from 'grapesjs';

@Component({
  selector: 'app-editor',
  templateUrl: './editor.component.html',
  styleUrl: './editor.component.css',
})
export class EditorComponent implements AfterViewInit, OnDestroy {
  // Resolved by the time ngAfterViewInit runs — that is the whole reason
  // initialisation lives there and not in ngOnInit.
  @ViewChild('editorHost') private host!: ElementRef<HTMLDivElement>;

  private editor?: Editor;

  ngAfterViewInit(): void {
    this.editor = grapesjs.init({
      container: this.host.nativeElement,
      height: '100%',
      width: 'auto',
      fromElement: false,
      // No persistence yet. Wire your own API before shipping — see Storage.
      storageManager: false,
      blockManager: {
        blocks: [
          {
            id: 'section',
            label: 'Section',
            category: 'Layout',
            content: '<section class="section"><h2>Headline</h2></section>',
          },
          {
            id: 'text',
            label: 'Text',
            category: 'Basic',
            content: { type: 'text', content: 'Edit me' },
          },
          { id: 'image', label: 'Image', category: 'Basic', content: { type: 'image' } },
        ],
      },
    });
  }

  ngOnDestroy(): void {
    // GrapesJS owns DOM nodes, document listeners and an undo stack. Angular
    // removes the host element; only destroy() releases the rest.
    this.editor?.destroy();
    this.editor = undefined;
  }
}

<!-- editor.component.html -->
<!-- GrapesJS takes this element over completely. Do not render Angular
     content inside it — the editor owns everything below #editorHost. -->
<div class="editor-shell">
  <div #editorHost class="editor-host"></div>
</div>

/* editor.component.css */
.editor-shell {
  display: block;
  block-size: 100dvh;
}

/* GrapesJS measures its container at init. A host with no resolved height
   produces an editor that mounts successfully and renders nothing. */
.editor-host {
  block-size: 100%;
}

That is the whole integration. The parts worth re-reading are the two lifecycle hooks: initialisation in ngAfterViewInit because the container has to exist first, and destroy() in ngOnDestroy because Angular removing the host element does not release what GrapesJS attached to the document.

Load the editor on its own route

The editor is the heaviest thing in most applications that contain one. Putting it behind a lazily-loaded route keeps it out of the initial bundle for every user who never opens it.

// app.routes.ts — the editor is the heaviest route in the app. Load it last.
import type { Routes } from '@angular/router';

export const routes: Routes = [
  { path: '', loadComponent: () => import('./home/home.component').then((m) => m.HomeComponent) },
  {
    path: 'pages/:id/edit',
    loadComponent: () => import('./editor/editor.component').then((m) => m.EditorComponent),
  },
];

The editor's lifetime has to be bound to the component's. Four pieces do that work, and each of them fails in a recognisable way when it is missing.

GrapesJS attaches a large number of listeners to its canvas and fires them continuously while a component is being dragged or resized. In a zone-based Angular application every one of those listeners schedules a change-detection pass, even though nothing in your component tree has changed.

// editor.component.ts (excerpt)
import { Component, NgZone, inject, signal } from '@angular/core';

export class EditorComponent {
  private readonly zone = inject(NgZone);

  readonly selectedTag = signal('');
  readonly savedAt = signal<Date | null>(null);

  private mount(host: HTMLElement): void {
    // The canvas fires pointer events continuously while a block is being
    // dragged. Creating the editor outside the zone keeps those from
    // scheduling a change-detection pass on every frame.
    this.zone.runOutsideAngular(() => {
      const editor = grapesjs.init({ container: host, height: '100%' });

      // Re-enter only where editor state has to become Angular state.
      editor.on('component:selected', (component) => {
        this.zone.run(() => this.selectedTag.set(component.get('tagName') ?? ''));
      });

      editor.on('storage:end:store', () => {
        this.zone.run(() => this.savedAt.set(new Date()));
      });

      this.editor = editor;
    });
  }
}

// Zoneless applications (provideZonelessChangeDetection) have no zone to
// leave. Set signals from the same editor events and drop NgZone entirely.

• Create the editor inside NgZone.runOutsideAngular() so canvas activity does not drive change detection.
• Re-enter with NgZone.run() only in the handlers where editor state has to become Angular state — a selection, a save timestamp, a validation error.
• If nothing in your UI reflects editor state, you never need to re-enter at all.
• In a zoneless application (provideZonelessChangeDetection) there is no zone to leave: write to signals from the same editor events and drop NgZone entirely.

The editor runs in the browser. GrapesJS builds its canvas from real DOM — it measures elements, creates an iframe and attaches document listeners — so initialisation has to happen in a browser context and must not run during a server render. Routes that merely display published output are unaffected: that is plain HTML and CSS and renders on the server like anything else.

// editor.component.ts — browser-only initialisation
import {
  AfterViewInit,
  Component,
  ElementRef,
  OnDestroy,
  PLATFORM_ID,
  ViewChild,
  inject,
} from '@angular/core';
import { isPlatformBrowser } from '@angular/common';
import type { Editor } from 'grapesjs';

export class EditorComponent implements AfterViewInit, OnDestroy {
  @ViewChild('editorHost') private host!: ElementRef<HTMLDivElement>;

  private readonly isBrowser = isPlatformBrowser(inject(PLATFORM_ID));
  private editor?: Editor;

  async ngAfterViewInit(): Promise<void> {
    if (!this.isBrowser) return;

    // A dynamic import keeps the editor out of the server bundle and off the
    // critical path of every route that never opens it.
    const { default: grapesjs } = await import('grapesjs');
    this.editor = grapesjs.init({ container: this.host.nativeElement });
  }

  ngOnDestroy(): void {
    this.editor?.destroy();
  }
}

• Guard initialisation so it only runs in the browser — the platform check and the render hook below both do this.
• Import the library dynamically so it never enters the server bundle.
• Render a placeholder of the same size during the server pass to avoid a layout shift when the editor appears.
• Publish routes that only render stored HTML and CSS need no guard at all.

The render-hook alternative

Recent Angular versions offer a render hook whose callbacks run on browser platforms only and never on the server. Where it is available it expresses the same guarantee without a platform check, and it pairs naturally with signal-based view queries.

// The same guard, expressed with the render hook instead of a platform check.
import { Component, ElementRef, afterNextRender, viewChild } from '@angular/core';
import type { Editor } from 'grapesjs';

@Component({ selector: 'app-editor', template: '<div #editorHost></div>' })
export class EditorComponent {
  private readonly host = viewChild.required<ElementRef<HTMLDivElement>>('editorHost');
  private editor?: Editor;

  constructor() {
    // afterNextRender callbacks run on browser platforms only — they never
    // execute on the server, so no isPlatformBrowser check is needed.
    afterNextRender(async () => {
      const { default: grapesjs } = await import('grapesjs');
      this.editor = grapesjs.init({ container: this.host().nativeElement });
    });
  }
}

Check which of these your Angular version supports before choosing. Both patterns exist to enforce the same rule — the editor initialises in the browser and nowhere else. angular.dev

A page builder is not one feature. It is nine subsystems that have to agree with each other, and GrapesJS ships all nine. This is the overview; the product-level decisions — pricing, roles, templates, publishing workflow — belong to the dedicated guide linked underneath.

• GrapesJS

  Canvas

  The editable surface, rendered in its own iframe so page styles cannot leak into your admin UI.

• GrapesJS

  Components

  The typed model behind every element: what it is, what it accepts, and which settings it exposes.

• GrapesJS

  Block manager

  The palette users drag from. A block is a named piece of content mapped to a component type.

• GrapesJS

  Style manager

  The CSS editing panel, configurable down to which properties a given user is allowed to change.

• Plugin

  Asset manager

  Image and media picking. The upload endpoint behind it is yours, so plugins here mostly connect it to a provider.

• Your Angular app

  Storage manager

  Load and save. GrapesJS defines the contract and calls your API — the persistence itself is your application's.

• GrapesJS

  Commands

  Named, callable actions — undo, preview, export, and anything you register yourself for toolbar buttons.

• GrapesJS

  Device manager

  The responsive breakpoints the canvas can be previewed and styled at.

• GrapesJS

  Panels

  The editor's own chrome — buttons, toolbars and regions, all replaceable if the editor sits inside an existing shell.

Eight of the nine ship with the editor or with a plugin. The one that is unavoidably yours is storage — which is also the one that has to know about your users, your permissions and your database.

Three artefacts, and mixing them up causes real data loss. Project data is the editable document; HTML and CSS are the published result. They are not interchangeable, because the export is lossy by design.

// Three outputs, three different jobs. Do not use one where you need another.

const projectData = editor.getProjectData(); // editable state → store this
const html = editor.getHtml();               // markup         → publish this
const css = editor.getCss();                 // styles         → publish this

// Reopening a saved project restores components, styles, pages and assets.
// Re-parsing exported HTML does not — it loses everything not in the markup.
editor.loadProjectData(projectData);

Reparsing exported HTML back into the editor is not a substitute for project data: it loses component types, traits, page structure and anything else that was not expressible in the markup. GrapesJS is an editor, not a CMS or a backend — where the artefacts go, and what happens to them afterwards, is your application's decision.

The asset manager is a picker, not a file service. Point it at an endpoint in your Angular application and it will POST the files there; everything after that — validation, storage, resizing, delivery — is yours to implement, which is what makes it possible to reuse the media library you already have.

// Assets go to your endpoint, under your auth — GrapesJS only POSTs files.
grapesjs.init({
  container: host,
  assetManager: {
    upload: `/api/projects/${projectId}/assets`,
    uploadName: 'files',
    multiUpload: true,
    credentials: 'include',
    headers: { 'X-Requested-With': 'XMLHttpRequest' },
    // Off by default is the safer choice: base64 images end up inside saved
    // markup and make every page row grow without limit.
    embedAsBase64: false,
    // Returning false aborts the upload before the request leaves the browser.
    beforeUpload: (files: File[]) =>
      files.every((file) => file.size <= MAX_UPLOAD_BYTES && ALLOWED_TYPES.has(file.type)),
  },
});

editor.on('asset:upload:start', () => this.uploading.set(true));
editor.on('asset:upload:end', () => this.uploading.set(false));
editor.on('asset:upload:error', (error) => this.uploadError.set(String(error)));

• Uploads go to your endpoint with your headers and credentials, so the same auth as the rest of the app applies.
• Validate before the request leaves the browser and again on the server — the client-side check is convenience, not a control.
• Return the stored URLs from your endpoint; the editor puts those URLs into the page, so they must be the ones you intend to serve.
• Turn off base64 embedding unless you want images inlined into saved markup, where they make every stored page grow without limit.
• Serve assets from a CDN or object store and keep the editor pointed at the public URL, not at your application origin.
• Load large libraries through a paginated endpoint rather than handing the editor thousands of assets at initialisation.

None of this prescribes a particular backend. S3, Cloudinary, a Laravel disk or a folder on a server all satisfy the same contract: accept a file, return a URL.

Registering a component type is how the editor learns about your product. A custom type gets its own settings panel, its own drag-and-drop rules, and a block in the palette — so content teams work with concepts from your domain instead of raw divs.

// pricing-table.type.ts — an application-specific building block.
import type { Editor } from 'grapesjs';

export function registerPricingTable(editor: Editor): void {
  editor.Components.addType('pricing-table', {
    // Lets the editor recognise the type again when a saved page is reparsed.
    isComponent: (el) => el.classList?.contains('pricing-table'),
    model: {
      defaults: {
        tagName: 'section',
        attributes: { class: 'pricing-table' },
        droppable: false,
        // Traits become the right-hand settings panel for this component.
        traits: [
          { type: 'text', name: 'plan', label: 'Plan name' },
          { type: 'number', name: 'price', label: 'Price' },
          { type: 'checkbox', name: 'featured', label: 'Highlight' },
        ],
        components: `
          <h3 data-gjs-type="text">Team</h3>
          <p data-gjs-type="text">$29 / month</p>
        `,
      },
    },
  });

  // A block is how the component reaches the user: one entry in the palette.
  editor.Blocks.add('pricing-table', {
    label: 'Pricing table',
    category: 'Commerce',
    content: { type: 'pricing-table' },
  });
}

Typical application-specific components

• Hero section
• Pricing table
• Product card
• Form
• Navigation
• Testimonial
• Feature grid
• Anything specific to your SaaS

Two things make a custom type useful. isComponent lets the editor recognise your type again when a saved page is re-parsed, and traits become the settings panel a non-technical user actually edits. Both are worth writing even for a simple component.

A plugin is a function that receives the editor instance, so nothing here is Angular-specific — anything published for GrapesJS works inside an Angular component. These are the four gaps teams hit first after the editor mounts.

Blocks and presets

What users drag. A bare editor has almost nothing in the palette, so this is the first thing every integration adds.

Browse the category

Plugin Basic Blocks

The starting palette — the blocks a new editor is missing on first run.

FreeView plugin

Grapesjs Tailwind

Tailwind classes in the editor, if your Angular app already ships Tailwind.

FreeView plugin

GrapesJS Bootstrap v5 Blocks

Bootstrap 5 components as draggable blocks.

FreeView plugin

Super Header for GrapesJS

Configurable header sections instead of hand-built markup.

$39.00View plugin

Storage and projects

Persistence, autosave and multi-project management — the layer around the storage contract from the section above.

Browse the category

Grapesjs Project Manager

Multiple projects in one editor, with a project list UI.

FreeView plugin

IndexedDB Storage

Local persistence in the browser — useful for drafts and offline editing.

FreeView plugin

Autosave & Restore — Crash Recovery for GrapesJS

Recovers unsaved work after a crash or an accidental navigation.

$12.00View plugin

Directus Storage

Storage backed by a Directus instance instead of a bespoke endpoint.

FreeView plugin

Rich text and forms

Better inline text editing and real form components. Both are capabilities users assume are built in.

Browse the category

GrapesJS Inline Text Editor — Compatible with CKEditor 5

Replaces the built-in rich text editor with CKEditor 5.

$69.00View plugin

TinyMCE 8 Inline Text Editor

Replaces the built-in rich text editor with TinyMCE 6.

$69.00View plugin

Grapesjs RTE Extensions

Extra formatting controls on the default rich text toolbar.

FreeView plugin

Plugin Forms

Form components with real inputs, validation traits and submission settings.

FreeView plugin

Assets, export and email

Media providers, export formats and the email preset, for the surfaces a builder grows into.

Browse the category

Grapesjs Cloudinary

Cloudinary as the asset backend, including transformations.

FreeView plugin

Export Zip

Exports the page as a downloadable ZIP of HTML, CSS and assets.

FreeView plugin

MJML Preset

MJML blocks so the same editor can produce email-safe markup.

FreeView plugin

Grapesjs A11Y Seo — Accessibility auditor + SEO for GrapesJS

Accessibility and SEO checks inside the editor, before a page is published.

FreeView plugin

Building a visual editor is possible in Angular — it is a known amount of work, not an impossible one. The question is which parts of it you want to own for the lifetime of the product.

"Build" is not a criticism — every one of these is buildable. It is a statement of who maintains it afterwards.
Facts in this table re-verified 2026-09-02.

No, and it is worth understanding why the question comes up. GrapesJS publishes an official React wrapper, so developers reasonably expect an Angular equivalent. There is not one. That leaves three approaches, and for most teams the first is the right answer.

A demo is one component. A product is four layers, and the editor is only one of them. This is the shape most teams converge on once the editor has real users behind it.

1. 01

   Angular application

   The shell, the router, and one lazily-loaded route that owns the editor.

   • App shell
   • Router
   • Editor route (lazy)
   ↓
2. 02

   GrapesJS instance

   Configured once, at initialisation: which components exist, what can be dragged, what can be styled.

   • Components
   • Blocks
   • Styles
   • Assets
   • Commands
   ↓
3. 03

   Application services

   The Angular layer between the editor and your API — and the only place authorisation decisions are made client-side.

   • Auth
   • API client
   • Permissions
   • Publishing
   ↓
4. 04

   Backend

   Where the artefacts live, and where every permission is enforced for real.

   • Projects
   • Assets
   • Users
   • Versions

Nothing in this diagram is GrapesJS-specific except the second tier. That is the point: the editor is a component in an ordinary Angular application, and the rest is the architecture you would have built anyway.

The editor is a large piece of software running inside your application. These are the places where that actually costs something.

Twelve things that separate a working demo from a route real users can be given.

1. ✓

   Install GrapesJS

   Dependency added and the stylesheet registered, globally or in the editor component.

   Read the section
2. ✓

   Initialise after view creation

   grapesjs.init() runs in ngAfterViewInit, against a container with a resolved height.

   Read the section
3. ✓

   Destroy the editor correctly

   editor.destroy() in ngOnDestroy, verified by navigating away and back without leaks.

   Read the section
4. ✓

   Handle browser-only initialisation

   Guarded so nothing runs during a server render, with a placeholder in its place.

   Read the section
5. ✓

   Connect storage

   A named storage registered, autosave tuned, and project JSON stored alongside HTML and CSS.

   Read the section
6. ✓

   Configure assets

   Uploads pointed at your endpoint, base64 embedding off, validation on both sides.

   Read the section
7. ✓

   Add custom components

   Your product's own building blocks registered as types, with traits and palette entries.

   Read the section
8. ✓

   Add the plugins you need

   Blocks, rich text and export chosen deliberately rather than accumulated.

   Read the section
9. ✓

   Implement permissions

   Who may edit, who may publish — enforced on the server, reflected in the UI.

   Read the section
10. ✓

    Sanitise published content

    Server-side sanitisation between saving a page and serving it to visitors.

    Read the section
11. ✓

    Monitor editor errors

    Editor exceptions reported to the same place as the rest of your Angular errors.

12. ✓

    Test responsive editing

    The device manager exercised on a touch device, not only in a desktop browser window.

    Read the section

Start with the open-source visual editor, connect it to your Angular application, and extend it with the plugins and integrations your product needs.