Editor.js: a block editor that stores content as JSON instead of HTML

The problem is the output format, not the editing experience

Most WYSIWYG editors treat HTML as the storage format. The editor renders markup, you save the markup, and every consumer of that content has to parse it again: a mobile client, a search indexer, a newsletter renderer, an email template. The README states the project's position directly: Editor.js outputs clean JSON data instead of heavy HTML markup, and lists Web, iOS, Android, AMP, Instant Articles, speech readers and AI chatbots as intended consumers. That list is the argument. A block is a typed object with an id, a type, and a data payload, so a renderer for one platform does not need to understand the DOM structure another platform produced. The audience is therefore teams building content platforms rather than teams dropping a rich text field into an admin form. If your only consumer is a browser that will render the same HTML you saved, the JSON detour buys you nothing.

How a block editor is assembled from tools

The core package is deliberately thin. According to the README, each Block is provided via a separate plugin, which the project calls a Tool. The core supplies the editing surface, the block lifecycle, the toolbox and the inline toolbar; the tools supply the actual content types. The README's own tool list is the clearest statement of scope: Heading, Quote, Image, Simple Image, Nested List, Checklist, Link embed, Embeds, Table, Delimiter, Warning, Code, Raw HTML, Attaches, Marker and Inline Code, each in its own repository under the editor-js organisation. That split has a visible consequence. Simple Image is described as working without a backend requirement, which implies the regular Image tool expects one, so the choice between them is really a choice about whether you are prepared to run an upload endpoint. The data flow is one-directional at the boundary: you construct an EditorJS instance with a tools map, the user edits blocks, and you call editor.save(), which the README shows returning a Promise. Nothing about persistence is decided for you.

Installing the core and registering the tools you actually need

The README gives a three-step installation: install Editor.js, install the tools you need, initialise an instance. The package is @editorjs/editorjs, available via NPM, Yarn or a CDN link to jsDelivr, with npm i @editorjs/editorjs as the documented command. Initialisation requires a mount point and a configuration object. The README's example uses a div with id editorjs and then new EditorJS({ tools: { /* ... your tools */ } }), imported as import EditorJS from '@editorjs/editorjs'. Note what the example does not contain: any actual tool. An empty tools map is a valid starting point but a useless editor, so the first real decision is which tools to add and how to key them in that map. Saving is a single call, const data = await editor.save(), and the README points to example/example.html in the repository for a fuller worked example, plus the configuration page on editorjs.io for the option set. The README does not enumerate config keys beyond tools, so treat the docs site as the source of truth for anything else.

The plugin-per-block model is the main cost

Flexibility here is not free. Every content type is a dependency you install, register, version and eventually upgrade, and the core repository does not ship them. That means a bug in the Table tool is a bug in a different repository with a different release cadence from the core, and the compatibility surface between core and tools is something you have to track yourself. The README's roadmap hints at why this matters: several items under Ecosystem improvements are still unchecked, including Editor.js DevTools, Editor.js Design System, Editor.js Preset Env, Editor.js ToolKit, a new core bundle system, and new documentation and guides. A Preset Env and a ToolKit would presumably reduce exactly the assembly work described above, and they are not done. The second limitation is sharper. Collaborative editing appears on the roadmap as a list of unchecked items: Inline Tools JSON format, Operations Observer, Executor, Manager and Transformer, Undo/Redo Manager, Tools API changes, server and communication, and updates to the basic tools. Real-time multi-cursor editing is therefore not a shipped capability according to this material. If concurrent editing is a requirement, Editor.js is the wrong starting point today.

What the roadmap says about the project's direction

The roadmap is unusually specific, which makes it useful for judging fit. The Unified Toolbars group is entirely checked: Block Tunes moved left, a vertical Toolbox, multiple Toolbox buttons per Tool, vertical Block Tunes, nested menus, separators, a Conversion Menu, and hints plus the Conversion and Inline toolbars moving onto the unified toolbar. In other words, the editing chrome has recently been reworked and that work is finished. Under Other features, blocks drag'n'drop, new cross-block selection and new cross-block caret moving are all unchecked, so selection across block boundaries is an area where behaviour may still be limited compared with editors that treat the document as one contenteditable region. The collaborative editing group is entirely unchecked. Reading the roadmap as a status report rather than a promise is the honest approach: the checked items describe what the current toolbar looks like, and the unchecked items describe what you should not assume exists.

The alternative: HTML-first editors such as Quill or TinyMCE

The obvious comparison is an HTML-first rich text editor. Quill and TinyMCE both hand you a document model rooted in markup or a Delta format and a large built-in feature set; you configure formats and toolbar buttons rather than installing separate packages per content type. The difference in approach is where the structure lives. In an HTML-first editor the structure is expressed in the DOM and you extract it afterwards, often with a sanitiser and a parser. In Editor.js the structure is the stored artefact, and rendering is your problem, which is why the README can claim the output is easy to sanitise and extend. The trade runs the other way for teams that want a working editor in an afternoon: with Quill or TinyMCE you get bold, italic, lists and links without leaving the package, while Editor.js leaves you to install Marker, Inline Code, Nested List and the rest one by one. Editor.js is also not a page builder or a document store. It is the editing surface and the JSON shape, and nothing else.

Maintenance, licensing and what to verify before adopting

The core is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant; that is a permissive licence, and it is not legal advice to say so. The licence of the core does not automatically extend to the tools, which live in separate repositories under the editor-js organisation and may carry their own terms, so check each tool you add. On maintenance cost, the release history shows a steady stream of patch releases on the v2.31.x line, with v2.31.6 dated 2026-04-07, v2.31.5 on 2026-03-11 and v2.31.4 on 2026-03-04, and the default branch is next rather than main, so the development line and the released line are not the same branch. The README also asks for donations through Open Collective, Patreon and crypto, and states plainly that if your business relies on Editor.js you will probably want it maintained. Treat that as a funding signal rather than a stability guarantee. Practical verification steps: confirm that a tool exists for every block type you need, check that the JSON shape editor.save() returns matches what your storage layer accepts, and decide early whether you are rendering that JSON server-side or client-side, because that renderer is code you own.

Editorial conclusion

Adopt Editor.js when the stored artefact matters more than the editing surface: headless CMS backends, mobile clients, or pipelines that need to sanitise and re-render content in several places. Do not adopt it if you expect a batteries-included editor, since the core ships no block tools and you must install and register each one yourself. Before committing, check whether the specific tools you need exist and are maintained, confirm the JSON schema your storage layer will accept, and note that collaborative editing is still an unchecked roadmap item rather than a shipped feature. The Apache-2.0 licence covers the core; individual tools are separate repositories with their own licences, so verify each one you install.

Official sources

1. codex-team/editor.js on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases