# Draftail is a keyboard-first rich text editor that lives on an archived engine

> Draftail is a configurable React rich text editor built on Draft.js, with autolists, Word paste handling, a large shortcut set and an extension API, and it now carries a note that its underlying library has been archived and no longer receives updates.

**wagtail/draftail** — 📝🍸 A configurable rich text editor built with Draft.js

- Repository: https://github.com/wagtail/draftail
- Website: https://www.draftail.org/
- Stars: 631 · Forks: 65
- Language: TypeScript
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/wagtail-draftail

## An editor designed for people who type

Draftail is described as a configurable rich text editor built with Draft.js, and the README states its aim plainly: a mouse-free, keyboard-centric experience. The features list follows from that.

There are lots of keyboard shortcuts, with the full set documented on the project site. There are autolists, so starting a line with a dash, a star or a number and a dot creates a list item. There are shortcuts for heading levels with a double hash, for code blocks with three backticks, and for text formats with double asterisks. Undo and redo are supported, and the README's phrasing about them running until the end of times is a fair description of a rich text editor that keeps a full history.

The common text types are headings, paragraphs, quotes and lists, and the common text styles are bold, italic and more beyond that. The API lets you build custom controls for links, images and other things the default toolbar does not offer.

Two of these deserve emphasis for an evaluation. The first is paste from Word, or from any other editor, which the README describes as simply working. Pasting is where rich text editors usually fall apart, because the clipboard carries formatting that has to be mapped onto the editor's own model, and Draft.js's paste handling is the part that most editors either avoid or rewrite. The second is the extension story, which is covered separately below.

The audience is therefore a React team that wants an editor they can configure deeply, rather than a fixed widget that either fits or does not.

## The dependency underneath is archived

The most important line in the README is a note rather than a feature, and it should be the first thing an adopter reads.

Draftail itself is maintained, the note says, but the underlying Draft.js library has been archived and no longer receives updates, with a link to the issue titled Draft.js no longer maintained. Everything else in this article is downstream of that fact.

What it means practically is a split maintenance burden. Draftail's own code, the toolbar, the extensions, the styling and the accessibility work continue to be maintained by Wagtail contributors. The editor model underneath, the entity system, the block handling and the key binding machinery, no longer receives fixes from its own maintainers. A bug in Draft.js will not be fixed upstream, and a security advisory against Draft.js will not be patched upstream, which means a project using Draftail inherits the risk of depending on an unmaintained engine.

That is not automatically a dealbreaker. Draft.js is a mature library, and plenty of software in production depends on archived dependencies without trouble. It becomes a problem when the editor's behaviour matters to you, when you need a new block type or a new entity, or when your organisation has a policy on unmaintained dependencies.

The project is candid about it, and it links the issue so that readers can judge for themselves. That candour is worth crediting, because the alternative, a wrapper that quietly sits on a dead engine, is the normal and much less useful case.

The same openness appears in the README's other commitments. The project adheres to Semantic Versioning, measures performance and code coverage, and tries to follow accessibility best practices, tested with aXe, with a request for help in that area linked as an issue.

## Extensions: custom controls and the draft-js-plugins ecosystem

The extension model is what separates Draftail from a plain rich text field, and the README describes it in two parts.

The first is the API for building custom controls for links, images and more. A control is a React component with its own state and behaviour, and the editor is responsible for showing it, positioning it and wiring it to the current selection. The supporting dependencies show the shape of that machinery: downshift for the combobox behaviour that link and image controls need, tippyjs/react for the floating positioning of those controls, and decorate-component-with-props to pass editor state down into the control components.

The second is compatibility with the draft-js-plugins ecosystem, which is described as a way to build more advanced extensions. The dependency list includes draft-js-plugins-editor, which is the entry point into that ecosystem, along with draftjs-conductor for the plugin architecture and draftjs-filters for the block and entity behaviour that plugins rely on.

This is a real advantage for a project whose editors need something the stock toolbar does not have, a custom colour picker, a bespoke link resolver, an internal component insertion flow. Building that with a contenteditable surface means fighting the browser's selection model, and Draft.js's plugin architecture is one of the better answers to that problem.

The cost is that you are committing to a plugin ecosystem that is itself built on the archived engine. The extensions will keep working, and the plugins are maintained separately, but the long-term story is tied to Draft.js's fate.

## What the package ships and which browsers it targets

The package metadata describes a library with three entry points, which is the shape a modern bundler-friendly React package has:

```json
  "name": "draftail",
  "version": "2.0.1",
  "main": "dist/draftail.cjs.js",
  "module": "dist/draftail.esm.js",
  "types": "dist/draftail.d.ts",
```

So a CommonJS consumer, an ES module consumer and a TypeScript consumer each get what they expect, and the type definitions ship with the package. The files array limits what is published to the dist directory and the SCSS sources, so the stylesheets are importable and the examples and tests are not shipped.

The browser support target is declared in the browserslist field:

```json
  "browserslist": [
    "> 1%",
    "not IE 11",
    "Firefox ESR",
    "not OperaMini all"
  ],
```

IE11 and Opera Mini are excluded, and Firefox ESR is included explicitly, which is the right call for a component library that ships to institutional and enterprise sites. The exclusion of IE11 is notable because it removes a class of selection and clipboard problems that would otherwise constrain the implementation.

The runtime dependencies are few and each has a clear job. The editor framework is Draft.js itself, which arrives as a peer rather than as something the package installs for you.

## The build, the examples and the test surface

The repository layout shows a project with real engineering around it rather than a component and a readme.

The build is driven by Rollup, with the rollup.config.js at the root and a TypeScript plugin in the dev dependencies. The examples are a Storybook setup in the .storybook directory, and the examples folder is organised into blocks, components, entities, plugins, sources and utils, with several story files. Two of those stories are worth noticing by name: a performance story and a tests story, which suggests performance and the test suite are treated as things you can see rendered, and not merely as things you can run in CI.

Testing is Jest, with a jest.config.js at the root, and the dev dependencies carry the testing-library packages, jest-axe for accessibility assertions and a user-event package. The presence of jest-axe as a typed dependency is consistent with the README's statement that accessibility is tested with aXe, and it means an accessibility regression can fail a test rather than only being noticed by a reviewer.

The surrounding tooling is thorough as well. There is a .babelrc.js, an .eslintrc.js with a separate .eslintignore, a .prettierignore alongside prettier.config.js, a stylelint.config.js for the SCSS, a tsconfig.json, a .nvmrc pinning the Node version, and a .githooks directory for the commit hooks. A CHANGELOG.md and a ROADMAP.md sit at the top level, and the ROADMAP is the place to look for the project's own view of where it is going.

The documentation site and the demos are hosted at draftail.org and are powered by Netlify, according to the credits, and the site has separate pages for getting started, the API reference, the user guide and getting started with extensions.

## Ownership, licence and the release history

Draftail was created by Springload and is now maintained by Wagtail contributors, and the licence is MIT with the licence file in the repository. That is a permissive licence with an attribution requirement, and it suits a component that other people are expected to embed in their own applications.

The ownership history explains the project better than the feature list does. A commercial consultancy built the editor for its own products, and handing it to the Wagtail community gave it a home with a large user base, a code of conduct, a contribution process and a release cadence. The Wagtail connection also explains the emphasis on accessibility, since that is a stated priority of the ecosystem, and the presence of a 2.0 major release in December 2024 suggests a willingness to make breaking changes when a new major version of the platform arrives.

The release history shows a long gap and then a burst. Version 1.4.1 came out on 2021-04-16, version 2.0.0 on 2024-12-21 and version 2.0.1 on 2025-02-12. The last push to the repository was on 2026-04-23, and the repository is not archived.

So the picture is of a maintained wrapper on an archived engine, with a recent 2.0 line and ongoing work. Whether that is enough depends entirely on how much you depend on the editor's internals.

## Conclusion

Draftail fits a React team, most obviously one inside the Wagtail ecosystem, that wants a rich text editor with a real extension model and keyboard-driven editing rather than a contenteditable box, and that is prepared to own the maintenance of the editor layer itself. It is the wrong choice for a new project that wants a maintained foundation, because the note in the README is explicit that Draft.js has been archived and no longer receives updates, and it is the wrong choice if you need a React 18 or 19 codebase, given the type dependencies in the manifest. Before adopting it, read the issue on Draft.js no longer maintained, check the React and Draft.js versions your application already uses, and read the ROADMAP.md, which is where the project's own view of its future is recorded.

## FAQ

### What is Draftail?

Draftail is a configurable rich text editor for React built with Draft.js, aiming at a mouse-free, keyboard-centric experience. It supports keyboard shortcuts, autolists, pasting from Word and other editors, common text types and styles, an API for custom controls and compatibility with the draft-js-plugins ecosystem.

### Is Draft.js still maintained?

No. The README carries a note that while Draftail itself is maintained, the underlying Draft.js library has been archived and no longer receives updates, and it links the issue on the topic for details.

### How do I add custom controls to Draftail?

Draftail provides an API to build custom controls for links, images and more, and it is compatible with the draft-js-plugins ecosystem for more advanced extensions. The getting started with extensions documentation covers the details.

### Which browsers does Draftail support?

The package targets browsers matching greater than one percent usage, excluding IE 11 and Opera Mini all, and including Firefox ESR. It ships CommonJS, ES module and TypeScript entry points, with the types in dist/draftail.d.ts.

### Who maintains Draftail and under what licence?

Draftail was created by Springload and is now maintained by Wagtail contributors, and it is MIT licensed. The documentation and demos at draftail.org are powered by Netlify.

## Sources

- [License: MIT](https://github.com/wagtail/draftail/blob/main/LICENSE)
- [Project website](https://www.draftail.org/)
- [README](https://github.com/wagtail/draftail/blob/main/README.md)
- [Releases](https://github.com/wagtail/draftail/releases)
- [wagtail/draftail on GitHub](https://github.com/wagtail/draftail)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/wagtail-draftail