Editor.js review: block-style content editing that outputs JSON

What Editor.js is, and who it is for

Editor.js replaces the WYSIWYG textarea. It is for products where users write documents — help centre articles, blog posts, internal wikis, product descriptions — and where the stored content needs to be structured rather than a blob of markup an intern pasted from Word.

The core idea is that a document is an ordered list of typed blocks, and each block owns its own data shape. A paragraph block stores text. An image block stores a URL, a caption and a stretched flag. Saving gives you JSON, and the JSON is yours to render wherever.

That model earns its keep the moment content has more than one destination. If the same article must appear on a website, in a native app and in a newsletter, HTML forces you to parse and rewrite it, while typed blocks let each surface render what it can and skip what it cannot.

It is emphatically not a page builder, and the most common failure with Editor.js is choosing it for a job that needs one. For those, GrapesJS or Puck are the right shape, and Editor.js vs Puck sets out where the line falls.

Architecture: blocks all the way down

The editor owns a contenteditable surface and manages a list of block instances. A block tool is a class with three obligations: render returns the DOM element the user edits, save extracts data from that element, and a static toolbox describes how it appears in the plus menu. Inline tools handle selection-level formatting; block tunes handle per-block settings such as alignment.

Two consequences follow. First, because tools own their own DOM, the editor is framework-agnostic — React, Vue and Angular integrations all amount to mounting it and getting out of the way. Second, because it is contenteditable underneath, anything involving selection, paste handling or nested interactive elements needs care; this is inherent to browser text editing, not a flaw in Editor.js.

Sanitisation is configured per tool. This is worth attention: user-authored content stored as structured JSON and rendered by your own code is safer than stored HTML, but only if you validate on the way in and escape on the way out.

Getting started

Five lines, the shortest of the eight libraries we measured.

import EditorJS from '@editorjs/editorjs';

new EditorJS({
  holder: 'app',
  data: { blocks: [{ type: 'paragraph', data: { text: 'Hello editor' } }] },
});

A median of 70 ms to a rendered editor, the fastest in our benchmark. Adding the block tools a real product needs — image, list, table, quote, code, embed — raises both that number and the bundle size, so treat 64.3 kB as a floor rather than a shipping figure.

Strengths

Structured output. JSON blocks are queryable, diffable, migratable and renderable anywhere. Compared with storing HTML, this is the difference between content you own and content you archive.

The smallest integration cost in this dataset. Five lines, one dependency, 70 ms. If your requirement genuinely is document authoring, nothing here gets you there faster.

A clean block tool contract. New content types are a class with two methods. Teams routinely ship custom blocks — call-to-action panels, product embeds, code samples with syntax choice — within a day.

Framework-agnostic and self-hosted. Apache-2.0, no service, no account, works in any stack, and the editor is stable enough that older tools generally keep working.

Good defaults for safety. Per-tool sanitisation, predictable output and no arbitrary pasted markup finding its way into your database.

Limitations

No layout, at all. No columns, no grid, no breakpoints, no style manager. Users get a vertical stack. If your users expect to place two things side by side, the core will not do it and the community tools that try are not a substitute for a layout engine.

You write the renderer. Nothing turns saved blocks into HTML for you. One renderer per surface, maintained as tools are added, and kept in sync with tool version changes. This is the hidden cost of the JSON model and it is rarely mentioned in comparisons.

Uneven third-party tools. The official tools are solid; beyond them quality varies, TypeScript types are inconsistent, and some widely linked tools have not kept pace with core releases.

Contenteditable behaviour. Paste handling, selection across blocks and mobile keyboard quirks are the usual browser text-editing difficulties. They are manageable, but they are real work when your users are demanding.

Not for email. Blocks are not table-based HTML, and getting from one to the other is a renderer you write and test across mail clients. See the email template builder use case.

Pricing

Free under Apache-2.0, including the official block tools, with no usage limits. The engineering cost is the renderer plus whatever custom blocks your product needs — smaller than any page builder in this dataset, and matched by a correspondingly narrower job.