# Editor.js vs Puck: writing documents or composing pages

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

## Summary

- Editor.js produces documents: a vertical stack of typed blocks, framework-agnostic, 64.3 kB gzip in our measurement.
- Puck produces pages: instances of your React components with props, arranged on a canvas, 90.4 kB gzip with React external.
- Products that need both usually need two editors, and forcing one library to do both jobs is the most reliable way to end up with a poor version of each.

## At a glance

| Product | Type | Licence | Frameworks | Bundle (min+gzip) | Price from | Self-hosted | White label | Score |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| [Editor.js](https://www.editorstack.cc/libraries/editorjs) | library | Apache-2.0 | Any (framework-agnostic) | 64.3 kB gzip | Free (open source) | Yes | Yes | 7.7 |
| [Puck](https://www.editorstack.cc/libraries/puck) | library | MIT | React | 90.4 kB gzip | Free (open source) | Yes | Yes | 8 |

## Two different verbs

Editor.js is for writing. The user types, and structure emerges from what they type — a heading, a
list, an image with a caption. The output is a document.

Puck is for arranging. The user picks components you built and places them, filling in the props you
exposed. The output is a page.

A help centre article is the first. A pricing page is the second. Most products eventually need both,
and the honest architecture is two editors rather than one stretched.

## Where Editor.js wins

**Writing feels like writing.** A contenteditable surface where text flows. In Puck, text is a prop
in a form field, and writers notice immediately.

**Framework-agnostic.** Mounts anywhere; Puck requires React.

**Content portable across surfaces.** Typed JSON blocks render on the web, in an app or in an email
from one stored representation. Puck's data means something only inside your React app.

**Cheaper to integrate**: five lines against sixteen, and 70 ms against 852 ms to a rendered editor.

**Users cannot break the layout**, because there is none.

## Where Puck wins

**Layout and composition.** Users arrange sections, choose variants and fill in props. Editor.js has
no concept of any of this.

**Your components render in the canvas.** What the editor shows is what production renders, and
interactive components — pricing tables, booking widgets, product carousels — work in both.

**Typed content against your config.** Renaming a prop is a compile error rather than a silently
broken page.

**Structure you control.** You decide what can exist on a page; Editor.js's structure is whatever
tools you installed, in whatever order the user typed them.

## Using both

The common architecture is Editor.js (or [Plate](/compare/editorjs-vs-plate)) for the article body,
and Puck for the page around it — with a "rich text" Puck component whose prop is a block document.

That composition works well and is much less exotic than it sounds. The alternative — a single
library serving both — produces either a page builder people write badly in, or a text editor people
lay out badly with.

## Migration

Editor.js to Puck: each block type becomes a component with props. Mechanical for standard blocks,
and it loses the flowing-text editing experience.

Puck to Editor.js: only sensible for content that was already a stack of text and images. Anything
with layout has nowhere to go.

## Verdict

Ask what the user is doing when they open the editor. If they are going to type a lot, Editor.js. If
they are going to arrange things, Puck. If both, build both — and use the boundary between them as a
product decision rather than a technical compromise.

If the arranging has to happen outside React, [GrapesJS vs Editor.js](/compare/grapesjs-vs-editorjs)
is the comparison that applies instead.

## Decision checklist

1. **What is the user doing in the first thirty seconds — typing or dragging?** That answers it.
2. **Do we need both an article editor and a page builder?** Many products do, and building both is
   more honest than stretching one.
3. **Is our stack React?** Puck requires it; Editor.js does not care.
4. **Should users be able to change layout?** Editor.js says no by construction.
5. **Where does the content render?** Editor.js blocks need a renderer per surface; Puck data renders
   through your React components only.

## The number that matters

One renderer per output surface — the recurring cost of Editor.js's JSON model that nobody mentions
when comparing installation snippets. If your content appears on a website, in an app and in an email,
that is three renderers to write and keep in step with your tool versions.


## Frequently asked questions

### Can Editor.js replace Puck for landing pages?

No. Editor.js has no layout, no columns and no component props — a landing page built from a linear block stack is a compromise you will keep apologising for.

### Can Puck replace Editor.js for articles?

Awkwardly. You would model a paragraph as a component and lose the flowing text-editing experience writers expect. Use a text editor for text.

### Which is lighter?

Editor.js at 64.3 kB against Puck's 90.4 kB, though Puck's figure excludes React on the basis that a React app already ships it.