# GrapesJS vs Puck: HTML canvas or React components?

*Source: https://www.editorstack.cc/compare/grapesjs-vs-puck — last updated 2026-09-17. Licensed CC BY 4.0 with attribution to EditorStack.*

## Summary

- Choose Puck if your product is React and the things users arrange should be your own React components; choose GrapesJS if the editor must run outside React or must produce standalone HTML.
- The measured difference is large: GrapesJS core is 294.6 kB gzip against Puck's 90.4 kB, though Puck's figure excludes React itself because a React app already ships it.
- Migration between them is not a port, it is a re-model: GrapesJS stores HTML and CSS, Puck stores a JSON tree of component names and props, and there is no mechanical conversion between the two.

## At a glance

| Product | Type | Licence | Frameworks | Bundle (min+gzip) | Price from | Self-hosted | White label | Score |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| [GrapesJS](https://www.editorstack.cc/libraries/grapesjs) | library | BSD-3-Clause | Any (framework-agnostic) | 294.6 kB gzip | Free (open source) | Yes | Yes | 7.5 |
| [Puck](https://www.editorstack.cc/libraries/puck) | library | MIT | React | 90.4 kB gzip | Free (open source) | Yes | Yes | 8 |

## The one difference that decides it

GrapesJS edits a document. Puck edits a tree of your components. Everything else follows from that.

In GrapesJS, the user manipulates HTML nodes inside an iframe canvas, and what you store is HTML
and CSS. That format is portable to anything that renders web markup — an email, a static site, a
PHP template — and it means the editor never needs to know what framework surrounds it.

In Puck, the user manipulates instances of React components you registered, and what you store is
JSON: component names plus the props each instance was given. That format is portable to exactly
one thing, your React application, and in exchange the editor renders the same components your
users will see in production, with no translation layer in between.

Neither is a better architecture in the abstract. They are answers to different questions.

## When GrapesJS wins

**The editor has to leave React.** A white-label builder resold to agencies whose sites are not
React, an editor embedded in a Vue admin panel, a template builder inside a Rails monolith — Puck
is not a candidate for any of these, and GrapesJS is designed for them. Mounting it is the same
small component in each framework; our [Vue guide](/guides/grapesjs-vue) and
[React guide](/guides/grapesjs-react-integration) show both, tested.

**The output has to be HTML.** Email is the clearest case. An email template must be table-based
HTML with inlined CSS, and a JSON tree of React components does not get you there without writing
a serialiser. GrapesJS has a newsletter preset that switches the whole component set to email-safe
primitives.

**Users need visual style control.** GrapesJS ships a style manager: users pick a node and change
padding, colour, typography, and the result is CSS. Puck deliberately has no style manager — layout
comes from the props your components expose, which is a feature if you want brand consistency and
a blocker if your users expect to design freely.

**You are handing the builder to end customers who expect a website builder.** The mental model
GrapesJS presents — canvas, layers, styles, breakpoints — is the one people already know from
Webflow and Elementor.

## When Puck wins

**Your components are the product.** If you have a design system and marketing needs to assemble
pages from it, Puck's config is a direct expression of that: register the component, declare its
editable fields, done. The canvas renders the real component, so what the editor shows is what
production renders, and there is no second implementation to keep in sync.

**You want typed content.** Puck's stored JSON is typed against your config, so a renamed prop is a
compile error rather than a page that silently loses a section. Storing HTML gives you no such
guarantee.

**You are on Next.js.** Puck's documentation and examples target the App Router directly, the
renderer works in server components, and there is no dynamic-import-with-SSR-disabled dance. Our
benchmark measured Puck at 852 ms to a rendered editor against GrapesJS at 309 ms — Puck is slower
to first paint because it boots React and an iframe preview — but that is a one-time editor load,
not a page-speed number your visitors experience.

**Bundle budget matters.** 90.4 kB gzip against 294.6 kB is a real difference, with the caveat that
Puck's measurement treats React as already present. See the
[bundle size benchmark](/research/bundle-size-benchmark-2026) for how both were measured.

## In code

The shapes of the two APIs make the difference concrete. GrapesJS takes a container and a document:

```js
import grapesjs from 'grapesjs';

grapesjs.init({
  container: '#app',
  components: '<section class="hero"><h1>Hello editor</h1></section>',
  blockManager: { blocks: [{ id: 'text', label: 'Text', content: '<p>Text block</p>' }] },
});
```

Puck takes a config describing your components and a data tree of instances:

```jsx
const config = {
  components: {
    Heading: {
      fields: { text: { type: 'text' } },
      defaultProps: { text: 'Hello editor' },
      render: ({ text }) => <h1>{text}</h1>,
    },
  },
};

<Puck config={config} data={data} onPublish={save} />;
```

Read the second one again: `render` is your component. That single line is the whole argument for
Puck, and the reason it cannot serve a non-React product.

## What migration actually costs

There is no converter, in either direction, and building one is not a weekend project.

**GrapesJS to Puck** means parsing stored HTML and mapping DOM structures onto component instances.
It works only if your stored pages were built from a constrained block set; free-form pages with
user-authored inline styles do not map onto typed props at all. Budget for a per-page manual pass
on anything that is not template-generated.

**Puck to GrapesJS** is more tractable, because rendering component instances to HTML is something
your app already does — you render the tree server-side, store the output, and accept that the
result is no longer structured. What you lose is the typing and the link back to the components.

The practical advice: pick based on where the editor has to run in three years, not on which API you
prefer this week. Framework portability is the expensive thing to add later; a nicer developer
experience is not.

## Verdict

For a React or Next.js product whose editable units are its own components, Puck is the better
tool and the faster route to something customers can use. For anything that must run outside React,
must emit portable HTML, or must give users real style control, GrapesJS is the one that can do the
job at all — and its cost shows up as the UI work and the 294.6 kB you have to plan for.

If the requirement is specifically email, neither is the shortest path: see
[GrapesJS vs Unlayer](/compare/grapesjs-vs-unlayer) and the
[email template builder use case](/use-cases/email-template-builder-for-saas). If you are weighing
either against buying a finished editor, the [build vs buy calculator](/use-cases/build-vs-buy-visual-editor)
puts hours against licence fees.


## Frequently asked questions

### Is Puck a replacement for GrapesJS?

Only for React products that want their own components as editable units. Puck cannot produce standalone HTML for an email or run inside a Vue application, which are two of the main reasons teams pick GrapesJS.

### Which one is faster to get into production?

For a React team, Puck — it ships an editor UI and stores typed JSON, so there is no export step and no HTML-to-component translation. GrapesJS reaches a demo quickly but needs a replacement UI before it is customer-facing.

### Can I use both?

Yes, and some products do: Puck for in-app page composition from product components, GrapesJS for a separate email or template builder where the output has to be portable HTML.