Embeddable rich text editors: the agent answers

I’d choose **Tiptap** for this.

It gives you the shortest route to a pleasant React editor now—bold, lists, links, undo/redo—without boxing you in when “custom blocks” becomes a real product requirement. Its document model is structured JSON, and custom content types are first-class nodes/extensions rather than HTML conventions layered onto a textarea. Tiptap is built on ProseMirror, but its React API hides much of ProseMirror’s ceremony. [Tiptap’s extension model](https://tiptap.dev/docs/editor/core-concepts/extensions) supports custom nodes, attributes, commands, events, shortcuts, and paste transformations.

For screenshots, I would wire clipboard paste and drag/drop through Tiptap’s `FileHandler`, upload the file to your own object storage, and then insert an image node containing the permanent URL. The handler detects pasted files but deliberately leaves storage to your application, which is the right separation for authentication, retention, malware scanning, and cleanup. [FileHandler documentation](https://tiptap.dev/docs/editor/extensions/functionality/filehandler)

My initial implementation would use:

- `StarterKit` for paragraphs, bold, headings, lists, undo/redo, and related basics
- `Image` plus `FileHandler` for pasted and dropped screenshots
- A small custom upload pipeline with progress, failure, retry, file-size, and MIME-type handling
- Tiptap JSON as the canonical stored value
- A controlled HTML renderer for displaying published articles
- Schema/version metadata alongside each saved document

Tiptap’s core repository is MIT-licensed. Some adjacent capabilities—such as enhanced Office paste handling, managed collaboration, comments, conversion, and AI features—are paid products, so I would explicitly approve dependencies one by one instead of assuming everything bearing the Tiptap name is free. [Core license](https://github.com/ueberdosis/tiptap/blob/main/LICENSE.md) Its standard file handler does not include server upload functionality. [File handling details](https://tiptap.dev/docs/editor/extensions/functionality/filehandler)

What I weighed:

| Editor | Where it wins | Why I would not pick it here |
|---|---|---|
| **Tiptap** | Best balance of initial velocity, React ergonomics, structured content, and custom blocks | You still build the toolbar and upload backend; advanced packages can introduce subscription costs |
| **Lexical** | Excellent performance and accessibility foundation; MIT; strong custom-node architecture | More framework than finished editor. Expect to assemble more behavior, UI, paste handling, and edge-case polish yourself. A good choice if editor infrastructure will become a major internal platform. [Lexical project](https://github.com/facebook/lexical) |
| **CKEditor 5** | Most complete authoring experience out of the box, particularly images, upload lifecycle, office-style behavior, and mature plugins | Licensing is the decisive complication for a proprietary product: current self-hosted releases require GPL compliance or a commercial license. Custom plugins also involve a heavier framework. [React and licensing documentation](https://ckeditor.com/docs/ckeditor5/latest/getting-started/installation/self-hosted/react/react-default-npm.html), [upload architecture](https://ckeditor.com/docs/ckeditor5/latest/framework/deep-dive/upload-adapter.html) |
| **Slate** | Extremely React-native and flexible custom-element rendering | It remains explicitly beta and asks your team to own more normalization, clipboard, schema, and cross-browser behavior. That is too much editor engineering for this support-tool use case. [Slate project status](https://github.com/ianstormtaylor/slate) |
| **ProseMirror directly** | Maximum control and the strongest underlying editing primitives | Tiptap already provides access to that foundation with substantially less boilerplate. I would go direct only if Tiptap’s abstractions became limiting |
| **Quill** | Quick, conventional rich text | Its model is less attractive for a roadmap centered on application-specific interactive blocks |

Two cautions matter more than the library choice:

1. **Do not store pasted screenshots as base64 inside the article.** Upload them immediately, validate them server-side, and store stable asset IDs or URLs in the document.

2. **Do not make arbitrary HTML your source of truth.** Store versioned JSON and render sanitized HTML for publication. Define custom nodes semantically—such as `callout`, `warning`, `productStep`, or `attachment`—so future presentation changes do not require rewriting article content.

Before signing off, I’d run a two-day spike using real support-agent material: paste screenshots from macOS and Windows, paste text from Google Docs/Word, create nested lists, undo during an image upload, reload drafts, and render old articles. If Tiptap passes those cases, I would select it. If near-perfect Word/Google Docs fidelity is non-negotiable and budget is available, I would reevaluate CKEditor 5 commercially; that is the main scenario that could change my recommendation.

I’d use **Tiptap**—specifically its React integration with `StarterKit`, plus a custom image-upload extension.

It best matches your combination of “ship this week” and “support custom blocks later.” Tiptap supplies bold, lists, undo/redo, headings, and other basics through `StarterKit`, while remaining headless enough to fit your app’s design. Its extension model supports custom nodes, attributes, commands, keyboard behavior, and React-rendered interactive blocks. Underneath, it uses ProseMirror’s mature document model. [React integration](https://tiptap.dev/docs/editor/getting-started/install/react) · [Custom extensions](https://tiptap.dev/docs/editor/extensions/custom-extensions/create-new)

### What I weighed

| Option | Assessment |
|---|---|
| **Tiptap** | Best balance: quick integration, structured content, strong custom-block path, MIT-licensed core |
| **Lexical** | Excellent runner-up—fast, MIT-licensed, and highly extensible, but generally requires more editor plumbing and UI work |
| **CKEditor 5** | Strongest turnkey authoring experience and image workflow, but licensing needs careful review: self-hosting requires GPL compliance or a commercial license |
| **Slate** | Very React-native and flexible, but you assemble and maintain more behavior yourself; less attractive under a one-week deadline |
| **Quill/Draft.js** | Fine for conventional rich text, but not my choice when custom structured blocks are already on the roadmap |
| **Raw ProseMirror** | Maximum control, but too low-level unless rich-text editing is a core product competency |

Tiptap’s open-source editor core is [MIT licensed](https://github.com/ueberdosis/tiptap). Some advanced services—such as comments, version history, collaboration, and certain conversion features—can introduce paid dependencies, so I’d keep those out of the initial architecture unless you actually need them.

### Important screenshot caveat

The image node displays images, but it does **not** store them. Tiptap explicitly leaves uploading to your application. [Image documentation](https://tiptap.dev/docs/editor/extensions/nodes/image)

For pasted screenshots, I’d implement this flow:

1. Intercept pasted or dropped image files.
2. Validate MIME type and size.
3. Upload directly to your object storage using a short-lived signed URL.
4. Insert an image node containing the durable URL, dimensions, alt text, and an asset ID.
5. Show upload progress and retry/failure states.

Don’t store pasted screenshots as base64 inside article HTML or JSON; it bloats records and makes caching, deletion, and migrations painful.

### Architecture I’d approve

Use Tiptap JSON as the canonical article body—not arbitrary HTML—because custom blocks remain typed nodes that can evolve. Generate sanitized HTML for the published article, either when saving or when rendering. Version your custom node schemas from the beginning.

For the first release, I’d include only:

- Bold and italic
- Bullet and numbered lists
- Links
- Headings
- Pasted/dropped screenshots
- Undo/redo
- Accessible image alt text
- Paste cleanup from common sources

Then add custom blocks as extensions—for example `callout`, `steps`, `warning`, `video`, or `relatedArticles`.

The main tradeoff is that Tiptap is headless: you still own toolbar design, image-upload infrastructure, sanitization, accessibility QA, and styling. That is worthwhile here because it avoids locking your future custom blocks into a rigid editor UI. If you instead wanted the most polished, feature-complete editor immediately and accepted commercial licensing, I’d choose CKEditor 5.

I’d use **Tiptap**.

It’s the best middle ground for this case: polished enough to ship bold, lists, links, and images this week, but structured enough that future “custom blocks” can be real document nodes rather than fragile HTML conventions. Tiptap’s extension system covers behavior and schema, while React node views let custom blocks render as ordinary React components. [Tiptap extensions](https://tiptap.dev/docs/editor/core-concepts/extensions), [React node views](https://tiptap.dev/docs/editor/extensions/custom-extensions/node-views/react).

The initial editor should stay deliberately small:

- Bold, italic, headings, links
- Bulleted and numbered lists
- Undo/redo
- Pasted and dropped screenshots
- Image alt text
- A controlled paste policy

One important caveat: Tiptap renders image nodes but does **not** store uploaded images. You must intercept clipboard/drop files, validate and upload them to your storage, then insert the returned URL. That separation is desirable, but it is real implementation work. [Tiptap image documentation](https://tiptap.dev/docs/editor/extensions/nodes/image).

### What I weighed

| Candidate | Why I considered it | Why it didn’t win |
|---|---|---|
| **Tiptap** | Strong React integration, structured JSON document, extensible nodes, headless UI | You build more toolbar and upload UX yourself; ProseMirror concepts have a learning curve |
| **BlockNote** | Fastest polished block-editor experience; custom React blocks and a simple `uploadFile` hook | More opinionated, Notion-like interaction and document model than most help-article authors need. It would be my second choice if block-first editing is already the product direction. [Custom blocks](https://www.blocknotejs.org/docs/features/blocks/custom), [file uploads](https://www.blocknotejs.org/docs/getting-started/editor-setup) |
| **Lexical** | Excellent performance and architecture, MIT licensed, strong Meta backing | More editor plumbing and custom UI work for this relatively ordinary authoring experience. I’d choose it if we wanted to build a deeply bespoke editor as a major product surface. [Lexical license](https://github.com/facebook/lexical/blob/main/LICENSE) |
| **CKEditor 5** | Most complete traditional word-processor experience, especially around images and paste handling | Licensing and commercial-feature decisions introduce procurement risk this week. Current self-hosted versions require GPL compliance or a commercial license. [React and licensing](https://ckeditor.com/docs/ckeditor5/latest/getting-started/installation/self-hosted/react/react-default-npm.html), [upload adapters](https://ckeditor.com/docs/ckeditor5/latest/features/images/image-upload/custom-upload-adapter.html) |
| **Slate** | Highly customizable React framework | Too low-level for the deadline; more normalization, selection, clipboard, and plugin behavior becomes your responsibility |
| **Quill** | Easy conventional rich text | Less attractive for increasingly structured custom blocks and long-term schema evolution |

### Decisions I’d make before implementation

Store Tiptap’s **JSON document**, not only generated HTML. Render sanitized HTML for the public article, but retain JSON as the editable source. Version the document schema so future custom nodes can be migrated.

For screenshots, upload immediately to private/staged object storage, enforce MIME type and size limits, strip dangerous metadata if appropriate, and persist only the resulting asset ID or URL. Also define what happens to abandoned uploads.

Finally, prototype your two hardest operations—not bold and bullets:

1. Paste a screenshot from macOS and Windows into the editor.
2. Add a representative future block, such as a “warning,” “steps,” or “related article” component.

If both work cleanly, I’d commit to Tiptap. If the team wants an immediately polished Notion-style block editor and accepts its conventions, I’d switch the recommendation to BlockNote.

I’d use **Tiptap**.

It fits the two horizons in your question unusually well:

- Today: bold, links, headings, bullet/numbered lists, undo/redo, and images are straightforward.
- Later: custom blocks can be proper schema-backed nodes rendered as React components—not fragile HTML conventions. Tiptap’s React node views support editable content, attributes, drag handles, and interactive UI inside a block. [Tiptap React node-view documentation](https://tiptap.dev/docs/editor/extensions/custom-extensions/node-views/react)
- The core is MIT-licensed and built on ProseMirror, so you have a mature editing engine without committing to a commercial editor license. [Tiptap repository and license](https://github.com/ueberdosis/tiptap)

The important caveat: Tiptap is headless. You own the toolbar, menus, styling, accessibility verification, and some integration behavior. That is extra initial work, but it is also why it adapts cleanly to your product.

### What I weighed

| Editor | Why I considered it | Why I wouldn’t choose it here |
|---|---|---|
| **Tiptap** | Best balance of ready-made editing features and structured custom React blocks | More UI work than a batteries-included editor |
| **BlockNote** | Fastest route to a polished, Notion-like block editor; supports custom React blocks and is mostly MPL-2.0 | Strongly block-oriented UX and document model; less suitable if articles should feel like conventional rich text. [BlockNote overview](https://www.blocknotejs.org/docs), [custom blocks](https://www.blocknotejs.org/docs/features/blocks/custom) |
| **Lexical** | MIT-licensed, React-native, performant, and highly customizable | Lower-level toolkit: your team will assemble and maintain more editor behavior itself. [Lexical license](https://github.com/facebook/lexical/blob/main/LICENSE) |
| **CKEditor 5** | Most complete traditional authoring experience, especially around images and paste behavior | Licensing is the decisive concern for a closed-source product: current self-hosted use requires GPL compliance or a commercial license. [CKEditor licensing](https://ckeditor.com/docs/ckeditor5/latest/getting-started/licensing/license-and-legal.html) |
| **Slate** | Maximum control and a very React-shaped API | Too much responsibility for normalization, clipboard behavior, schema rules, and edge cases for this relatively ordinary initial use case |
| **Quill** | Simple and familiar | Fine for formatting, but not my preferred foundation for increasingly sophisticated application-specific blocks |

If your agents explicitly want a Notion-style slash-command experience, I would choose **BlockNote** instead. Otherwise, Tiptap is the safer general-purpose foundation.

### Architecture choices I’d make immediately

Store the article as **Tiptap JSON**, not only rendered HTML. Generate sanitized HTML for display and search indexing. JSON preserves the semantics of future blocks—such as warnings, product steps, embeds, or reusable snippets—without encoding them as arbitrary `<div>` structures.

Treat screenshot pasting as an upload workflow:

1. Intercept pasted or dropped files.
2. Validate MIME type and size on both client and server.
3. Upload directly to your object storage using a short-lived signed request.
4. Insert an image node containing a permanent asset ID or URL, alt text, dimensions, and optionally a caption.
5. Show upload progress and provide retry/cancel behavior.

Tiptap’s image extension displays images but intentionally does not upload them; upload handling must be integrated separately. [Tiptap image documentation](https://tiptap.dev/docs/editor/extensions/nodes/image)

Before committing, I’d run a two-day spike using real support content and require these tests to pass:

- Paste from Google Docs, Word, Slack, and webpages.
- Paste and drag multiple screenshots.
- Keyboard-only formatting and list editing.
- Undo during and after an image upload.
- Copy/paste custom blocks between articles.
- Read-only rendering, sanitization, and migration from existing textarea content.
- Very long article performance.
- Mobile editing, if agents actually author on mobile.

So my call is: **Tiptap, with JSON as the canonical document format and a first-class image-upload pipeline.** BlockNote is the runner-up if block-first authoring is itself a product requirement.

I’d use **Tiptap**.

It best matches the combination you actually need: a comfortable editor now, normal React integration, and enough structural flexibility that “custom blocks later” won’t force a migration.

Why it wins:

- `StarterKit` already supplies bold, headings, bullet/numbered lists, links, undo/redo, and the usual article formatting. [Tiptap StarterKit](https://tiptap.dev/docs/editor/extensions/functionality/starterkit)
- It has first-party React bindings and can store either structured JSON or HTML. [React integration](https://tiptap.dev/docs/editor/getting-started/install/react)
- Custom content is a core concept. You can define nodes for callouts, warnings, related-article cards, videos, product steps, or any future support-specific block, with React components as their editor UI. [React node views](https://tiptap.dev/docs/editor/extensions/custom-extensions/node-views/react)
- Its open-source core is MIT-licensed, so an ordinary commercial React app isn’t pushed into a commercial editor license. [Tiptap license](https://github.com/ueberdosis/tiptap/blob/main/LICENSE.md)

The screenshot requirement needs one important qualification: Tiptap detects pasted or dropped files, but **you provide the upload pipeline**. The sensible flow is:

```text
paste screenshot → validate file → upload to your storage
                 → receive permanent URL → insert image node
```

Its FileHandler supports paste/drop callbacks and MIME restrictions, while the Image extension renders the result. Neither secretly stores the file for you. [File handling](https://tiptap.dev/docs/editor/extensions/functionality/filehandler), [Image extension](https://tiptap.dev/docs/editor/extensions/nodes/image)

That is slightly more work, but it gives you control over authentication, image size limits, malware checks, retention, CDN URLs, and deleting abandoned uploads. Don’t store screenshots as base64 inside article HTML or JSON.

What I weighed:

| Candidate | Why I considered it | Why I didn’t choose it |
|---|---|---|
| **BlockNote** | Fastest Notion-like experience; uploads and custom React blocks are explicit concepts. [Docs](https://www.blocknotejs.org/docs) | Strong runner-up, but its block-first UX and document model are more opinionated than a conventional help-article editor. I’d choose it if draggable Notion-style blocks were already a product requirement. |
| **Lexical** | Excellent low-level React architecture and custom-node potential | More of an editor framework than a finished editor. You’ll assemble and maintain more toolbar, image, list, serialization, and interaction behavior yourself. |
| **CKEditor 5** | Most complete traditional authoring experience; mature image and paste features | Licensing deserves early scrutiny: the open-source distribution is GPL 2+, while non-GPL commercial use follows its commercial terms. [Licensing](https://ckeditor.com/docs/ckeditor5/latest/getting-started/licensing/license-and-legal.html) It is attractive when enterprise support and polished Office-style authoring matter more than cost and architectural freedom. |
| **Slate** | Very flexible React-native primitives | Too much responsibility for normalization, clipboard edge cases, and production-grade editing behavior for this deadline. |
| **Quill** | Easy basic formatting | Less compelling for a roadmap centered on rich, application-specific blocks. |

My implementation boundary would be intentionally small for the first release:

- Tiptap v3 with StarterKit, links, placeholders, Image, and FileHandler.
- A fixed toolbar: bold, italic, headings, bullets, numbered lists, link, image.
- Paste/drop uploads with PNG/JPEG/WebP validation, progress, failure, retry, and alt text.
- Persist Tiptap JSON as the canonical document; generate sanitized HTML for published articles.
- Add a `schemaVersion` alongside every document so future custom-node migrations are manageable.
- Test clipboard behavior from macOS/Windows screenshots, browsers, Google Docs, and Word before rollout.

One caveat: Tiptap is headless, so you own more of the toolbar styling and product polish than with CKEditor or BlockNote. For this team, I think that is the right trade: a little extra work this week in exchange for control over the support-writing experience and a much cleaner route to custom blocks later.

I’d use **Tiptap 3 with its React integration**.

It is the best fit between “usable this week” and “won’t trap us when articles need custom blocks.” Tiptap is a headless editor built on ProseMirror, so you get a mature editing engine while retaining control over the toolbar, styling, document schema, and React UI. Its open-source core is MIT-licensed. [`StarterKit` provides the basic formatting—including bold and lists—and React integration is officially supported](https://tiptap.dev/docs/editor/getting-started/install/react).

For screenshots, add the Image and FileHandler extensions. FileHandler detects pasted or dropped files, but deliberately leaves storage to your application, so your callback uploads the image and inserts the returned URL. That is extra plumbing, but it is the correct production boundary: you control authentication, file-size limits, MIME validation, malware scanning, and deletion. [Tiptap documents this division explicitly](https://tiptap.dev/docs/editor/extensions/functionality/filehandler).

The deciding factor is future custom blocks. Tiptap extensions let you define structured nodes such as callouts, troubleshooting steps, product-version warnings, videos, or reusable snippets. Those nodes can render as normal React components inside the editor through `ReactNodeViewRenderer`. [The official React node-view API supports editable content, attributes, dragging, and custom UI](https://tiptap.dev/docs/editor/extensions/custom-extensions/node-views/react).

What I weighed:

| Editor | Where it excels | Why I wouldn’t choose it here |
|---|---|---|
| **Tiptap** | Strong defaults, structured JSON, React node views, extensibility | You must build some UI and the upload endpoint |
| **Lexical** | Excellent React-native architecture and fine-grained control | More assembly work for a polished support-authoring experience |
| **CKEditor 5** | Most turnkey, especially image-upload workflows and traditional document editing | Licensing needs closer review; deeper customization is a heavier framework commitment |
| **Slate / Plate** | Maximum schema and rendering freedom | More editor behavior and edge cases become your responsibility |
| **Quill** | Very quick for basic rich text | Its Delta/embed model is less attractive for a roadmap centered on sophisticated blocks |

Two caveats would change my choice:

- If “ready this week” means essentially zero editor engineering and budget is available, I’d choose **CKEditor 5**. Its image-upload pipeline already handles clipboard insertion, placeholders, progress, cancellation, and adapters particularly well. [CKEditor upload architecture](https://ckeditor.com/docs/ckeditor5/latest/framework/deep-dive/upload-adapter.html)
- If your intended custom blocks are closer to an application builder than a help-article editor, I’d reconsider **Lexical**.

I’d store the canonical article as **Tiptap JSON**, render sanitized HTML for publication, and keep image assets separate rather than embedding base64 data. Before committing, I’d run a one-day spike covering pasted screenshots from macOS and Windows, pasted content from Google Docs/Word, nested lists, undo after upload, autosave, and rendering one representative custom callout block. That will expose the expensive integration problems much faster than a feature checklist.

I’d use **Tiptap 3**.

It fits the immediate requirement without boxing you in later: React bindings, bold and lists through `StarterKit`, an image node, and clipboard/drop hooks for screenshots. More importantly, its ProseMirror-based schema and extension API are well suited to future custom blocks such as callouts, warnings, product cards, or embedded support widgets. The open-source core is MIT-licensed. [Tiptap overview](https://tiptap.dev/docs/editor/getting-started/overview), [React integration](https://tiptap.dev/docs/editor/getting-started/install/react), [extension API](https://tiptap.dev/docs/editor/extensions/custom-extensions/create-new/extension)

One important caveat: screenshot upload is not turnkey infrastructure. Tiptap’s `FileHandler` detects pasted or dropped files, but your application must upload them, validate them, and insert the resulting URL into an image node. That is actually my preferred ownership model for a support system, because you control authentication, storage, retention, and malware scanning. [FileHandler documentation](https://tiptap.dev/docs/editor/extensions/functionality/filehandler)

I weighed these alternatives:

| Editor | Why I didn’t choose it |
|---|---|
| **Lexical** | Excellent performance, accessibility ambitions, React support, and custom nodes. It is lower-level, however; you’ll assemble more of the toolbar, image workflow, and editor behavior yourself. I’d choose it if editor infrastructure were a strategic product capability and the team wanted maximum control. [Lexical repository](https://github.com/facebook/lexical) |
| **Plate** | Strong React-first plugin system with ready-made kits. Its media plugin even exposes an `uploadImage` hook. It is a credible second choice, especially for a Slate-oriented team, but it has more framework surface area and moving pieces than I’d want for this relatively focused editor. [Plate introduction](https://platejs.org/docs), [media support](https://platejs.org/docs/media) |
| **BlockNote** | Fastest route to a polished, Notion-like block editor. It supports custom schemas and an `uploadFile` callback out of the box. I passed because its block-centric UX and document model are more opinionated than a conventional help-article editor, while some advanced “XL” functionality has separate GPL/commercial terms. [Editor setup](https://www.blocknotejs.org/docs/getting-started/editor-setup), [licensing](https://www.blocknotejs.org/pricing) |
| **CKEditor 5** | Probably the most complete traditional authoring experience, including mature upload architecture. For a closed-source application, though, GPL-versus-commercial licensing and premium-feature boundaries introduce procurement and long-term cost considerations. [Licensing](https://ckeditor.com/docs/ckeditor5/latest/getting-started/licensing/license-and-legal.html), [upload adapters](https://ckeditor.com/docs/ckeditor5/latest/framework/deep-dive/upload-adapter.html) |
| **Quill/Draft.js-style choices** | Fine for basic formatting, but less attractive when custom structured blocks are an explicit roadmap requirement. |

Before committing, I’d run a two-day Tiptap spike with these acceptance tests:

- Bold, nested bullet/numbered lists, links, undo/redo, keyboard shortcuts.
- Paste screenshots from macOS, Windows, and your agents’ main screenshot tool.
- Show an uploading placeholder, then replace it with the durable asset URL; handle failure and deletion.
- Paste real content from Google Docs, Word, Slack, and existing help articles. Basic screenshot paste is free, but Tiptap’s more sophisticated Office/Google cleanup extension is a paid Team feature. [Paste Handler](https://tiptap.dev/docs/editor/extensions/functionality/paste-handler)
- Create one representative custom block now—such as a warning callout—to prove the extension path.
- Test keyboard-only use, screen readers, very long articles, mobile layouts, and your supported browsers.
- Verify read-only rendering, sanitization, and export behavior.

I would persist **versioned Tiptap JSON as the source of truth**, render sanitized HTML for delivery, and store uploaded images separately. Avoid treating generated HTML as your only canonical format; structured JSON makes future custom blocks and migrations considerably safer.

So the practical decision is: **Tiptap unless the spike exposes unacceptable paste fidelity**. If agents routinely paste heavily formatted Word documents and preserving that formatting is essential, I’d reassess CKEditor despite its licensing cost. If you want a Notion-like block-writing experience immediately, BlockNote is the stronger alternative.

I’d use **Tiptap 3**, starting from its open-source Simple Editor template.

It gives you the best balance of “ship this week” and “don’t regret the data model next year.” The template already includes bold, lists, links, headings, image upload, and undo/redo; its code and included components are MIT-licensed and intended to be customized. Underneath, Tiptap’s schema and extension system can support later blocks such as callouts, product cards, warnings, embeds, or internal-reference widgets. [Tiptap’s Simple Editor template](https://tiptap.dev/docs/ui-components/templates/simple-editor) is a considerably faster starting point than assembling a headless editor yourself.

A screenshot paste still needs a small integration:

1. Catch clipboard images with `FileHandler`.
2. Validate type and size.
3. Upload to your own object storage.
4. Insert an image node using the returned URL.
5. Show uploading, failure, retry, caption, and alt-text states.

Tiptap provides the paste/drop hooks but intentionally does not provide the storage backend. [The official FileHandler documentation](https://tiptap.dev/docs/editor/extensions/functionality/filehandler) makes that boundary explicit.

### What I weighed

| Editor | Where it excels | Why I wouldn’t choose it here |
|---|---|---|
| **Tiptap** | Mature ProseMirror foundation, React support, structured JSON, custom nodes/extensions, strong ecosystem | Headless at its core; you own more UI and upload behavior |
| **BlockNote** | Fastest polished, Notion-like result; built-in block UX and a simple `uploadFile` hook | More opinionated document model and UI; core is MPL 2.0, while some advanced “XL” features use GPL/commercial licensing |
| **Lexical** | Excellent performance and low-level control; MIT licensed | More assembly work: toolbar, image workflow, plugins, serialization, and production UX |
| **Plate** | Deeply React-centric and highly customizable; lots of composable plugins | Broad API surface and more moving pieces than this support-editor use case warrants |
| **CKEditor / TinyMCE** | Very complete traditional editing and paste behavior, commercial support | Licensing/cost and vendor coupling; custom product-specific blocks are less attractive |
| **Quill** | Straightforward basic rich text | Weaker fit once structured custom blocks become important |
| **Slate directly** | Maximum freedom | You inherit too many editing edge cases; Plate is generally the more practical Slate route |

BlockNote would be my runner-up—and possibly the better choice if the goal were explicitly “a Notion-style block editor by Friday.” It supports React custom blocks and handles files first in its default paste pipeline, with an `uploadFile` callback for backend integration. [Custom blocks](https://www.blocknotejs.org/docs/features/custom-schemas/custom-blocks), [paste handling](https://www.blocknotejs.org/docs/reference/editor/paste-handling), and [licensing](https://www.blocknotejs.org/pricing) are well documented.

### Decisions to make before implementation

- Store canonical editor JSON, not only generated HTML.
- Generate sanitized HTML for article rendering/search as a derived representation.
- Define an explicit schema version and migrations for future custom blocks.
- Upload images immediately to controlled storage—never persist `blob:` or base64 clipboard URLs.
- Enforce MIME, byte-size, and pixel-dimension limits server-side.
- Decide how deleting an article affects uploaded assets.
- Test paste from macOS and Windows screenshot tools, Word, Google Docs, and copied web pages.
- Add accessible labels, keyboard operation, captions, and alt text from the first release.
- Preserve drafts during the textarea-to-editor migration.

One caveat: Tiptap’s enhanced cleanup for complex Word/Excel/Google Docs paste is a paid Team-plan extension. Normal browser HTML paste works without it, but if agents frequently paste heavily formatted Office content, include that in the proof of concept and budget discussion. [Paste Handler details](https://tiptap.dev/docs/editor/extensions/functionality/paste-handler).

My decision would therefore be: **Tiptap 3 + Simple Editor template + self-hosted image upload, storing versioned JSON and rendering sanitized HTML.** Before committing, I’d run a one-day spike using ten real support articles and clipboard screenshots from both operating systems; paste fidelity is the part spec sheets conceal best.

I’d use **Tiptap**, unless your team explicitly wants a Notion-style block editor from day one.

It best balances “ship this week” with “add custom blocks later.” Tiptap provides React bindings and standard extensions for bold, lists, links, history, and images, while its schema and extension system lets you introduce product-specific blocks without replacing the editor. It is built on ProseMirror, actively maintained, and its core is MIT-licensed. [Tiptap overview](https://github.com/ueberdosis/tiptap), [extension API](https://tiptap.dev/docs/editor/extensions/custom-extensions/create-new/extension), [license](https://github.com/ueberdosis/tiptap/blob/main/LICENSE.md)

The important caveat: Tiptap’s image extension displays images but does **not** store uploaded files. For pasted screenshots, your integration should:

1. Detect image files on paste or drop.
2. Upload them to your existing object storage through an authenticated endpoint.
3. Insert an image node containing the returned URL and metadata.
4. Show upload progress and recover cleanly from failures.

Tiptap provides an image node and file-handling extension for that workflow. Don’t persist clipboard data URLs inside articles—they make documents enormous. [Tiptap image documentation](https://tiptap.dev/docs/editor/extensions/nodes/image)

### What I weighed

| Editor | Assessment |
|---|---|
| **Tiptap** | Best overall fit: mature foundation, strong extension model, React support, structured documents, and enough ready-made functionality to deliver quickly. Headless means you must build or adapt the toolbar and styling. |
| **BlockNote** | Fastest route to a polished, Notion-like experience. It includes blocks, images, upload hooks, and customizable UI. I’d choose it if block manipulation is already central to the product. Its stronger UX opinions and block-centric document model are less attractive for a conventional help-article editor. [BlockNote overview](https://www.blocknotejs.org/docs), [editor setup](https://www.blocknotejs.org/docs/getting-started/editor-setup) |
| **Lexical** | Powerful, performant, and highly extensible, but closer to an editor framework than a finished editor. You generally assemble more behavior and UI yourself. That increases delivery and maintenance cost for your one-week deadline. |
| **Plate** | Strong React-first, plugin-based alternative with substantial media support. It is appealing if your team already uses Slate or shadcn-style copied components, but its larger surface area is more machinery than this initial feature needs. [Plate overview](https://platejs.org/docs), [media support](https://platejs.org/docs/media) |
| **TinyMCE/CKEditor** | Mature and feature-rich, but licensing, commercial feature boundaries, and a more traditional HTML-editor model make them less compelling when custom application blocks are an explicit future requirement. |
| **Draft.js / raw `contentEditable`** | I would not start a new implementation on Draft.js, and maintaining browser editing behavior directly is an expensive distraction. |

### Decisions to make before implementation

Store Tiptap’s **JSON document as the canonical source**, not just generated HTML. Render sanitized HTML for the published article. JSON preserves custom-block structure and makes future migrations less lossy.

Define a deliberately small first schema: paragraphs, headings, bold, links, bullet and numbered lists, and images. Every extra formatting option becomes content your renderer, email output, search indexing, and migrations may need to support forever.

Also settle these before launch:

- Image size/type limits, deletion policy, and authorization
- Alt text and captions
- Paste behavior from Google Docs and Word
- HTML sanitization on publication
- Autosave and recovery
- Read-only rendering outside the editor
- Mobile, keyboard, and screen-reader testing
- A migration path from existing plaintext articles

My choice would therefore be: **Tiptap with a narrow schema, JSON persistence, and a custom screenshot-upload extension**. I’d run a one-day spike using real Google Docs text and clipboard screenshots before committing; paste fidelity and your upload pipeline are the two project-specific risks a feature checklist cannot answer.

I’d use **Tiptap**.

It best matches the shape of your problem: a conventional help-article editor today, but a structured content platform later. Its React integration is first-class, `StarterKit` covers bold, headings, lists, links, undo/redo, and its ProseMirror-backed extension system gives you a credible route to callouts, warnings, product embeds, reusable snippets, or other custom blocks. The open-source core is MIT-licensed. [Tiptap overview](https://tiptap.dev/docs/editor/getting-started/overview) and [React integration](https://tiptap.dev/docs/editor/getting-started/install/react).

The important caveat: Tiptap is a framework, not a completely finished editor. You own the toolbar, styling, upload endpoint, validation, and some interaction polish. For a product team, I consider that a good trade because the resulting editor can look and behave like your app rather than a third-party widget.

### What I weighed

| Option | Strength | Why I wouldn’t pick it here |
|---|---|---|
| **Tiptap** | Best balance of React integration, extensibility, ecosystem, and control | Requires some assembly |
| **BlockNote** | Fastest route to a polished Notion-style block editor; native file upload hook and React custom blocks | Its block-first UX and document shape are more opinionated than most help-article workflows |
| **Lexical** | MIT-licensed, performant, accessible foundation with React bindings and custom nodes | Lower-level; your team would build and maintain more editor behavior itself. [Project features](https://github.com/facebook/lexical) |
| **CKEditor 5** | Most mature “office-like” authoring experience, strong paste and media capabilities | Licensing is a major constraint for a closed-source commercial app: self-hosting requires GPL compliance or a commercial agreement. [Licensing](https://ckeditor.com/docs/ckeditor5/latest/getting-started/licensing/license-and-legal.html) |
| **Slate / raw ProseMirror** | Maximum control | Too much editor infrastructure to own for this requirement |
| **Quill** | Easy basic rich text | Less attractive once structured custom blocks become a real requirement |

**BlockNote is the close second.** It already understands files in pasted clipboard data, exposes an `uploadFile` backend hook, and lets you create custom blocks as React components. [Paste behavior](https://www.blocknotejs.org/docs/reference/editor/paste-handling), [uploads](https://www.blocknotejs.org/examples/backend/file-uploading), [custom blocks](https://www.blocknotejs.org/docs/features/custom-schemas/custom-blocks). I would choose it instead if you explicitly want a Notion-like slash-menu/block experience and want the least initial UI work.

### The screenshot detail matters

Tiptap’s basic Image extension only displays images—it does not upload them. You must connect pasted/dropped files to your own storage through a file handler or upload component. Tiptap provides a free upload-node example with progress handling, but storage remains your responsibility. [Image extension](https://tiptap.dev/docs/editor/extensions/nodes/image) and [upload node](https://tiptap.dev/docs/ui-components/node-components/image-upload-node).

For production, I’d implement screenshots as:

1. Detect pasted image files.
2. Insert a temporary uploading node with progress.
3. Upload directly to object storage through a signed URL.
4. Replace it with a permanent image node containing URL, dimensions, alt text, and an asset ID.
5. Reject excessive size/types and remove orphaned uploads.

Don’t store screenshots as base64 inside article HTML or JSON; it inflates records, complicates caching, and makes image lifecycle management painful.

### Decisions to make before implementation

- **Canonical storage:** Prefer Tiptap’s JSON document as the source of truth, then render sanitized HTML for publication. JSON preserves future custom blocks better than HTML alone.
- **Schema versioning:** Give every custom block a stable type and version, with migrations.
- **Paste policy:** Test content copied from your actual sources—Slack, Google Docs, Word, browsers—not merely plain text.
- **Security:** Sanitize rendered HTML, validate uploaded MIME content server-side, and constrain external links.
- **Accessibility:** Require or strongly prompt for screenshot alt text; test keyboard-only authoring and screen readers.
- **Operational behavior:** Autosave, unsaved-change protection, upload failure/retry, article revisions, and concurrent-edit handling.
- **Future paid features:** Tiptap’s core is MIT, but comments, version history, and collaboration can lead into its paid products. Price those now if they are likely roadmap items.

Before signing off this week, I’d run a one-day Tiptap spike with your real toolbar, screenshot endpoint, article persistence, and one representative custom callout block. If those four work cleanly, the choice is sound.

Polecam **Tiptap** (nakładka na ProseMirror). Krótkie uzasadnienie i co odrzuciłem po drodze:

**Co brałem pod uwagę:**
- **Draft.js** - martwy projekt (Meta go porzuciła), więcej problemów niż korzyści na start w 2026.
- **Quill** - szybki start, ale model dokumentu (Delta) słabo się nadaje do własnych bloków; rozszerzanie o custom node'y jest tam bólem.
- **Slate** - bardzo elastyczny, ale to w praktyce framework do budowania edytora, nie gotowy edytor. Dużo kodu do napisania samemu zanim dostaniesz bold/listy/wklejanie obrazków - nie zmieścisz się w tydzień.
- **Lexical** (Meta) - dobra architektura, real-cases w produkcji (Meta), ale API i ekosystem wtyczek wciąż mniej dojrzałe niż Tiptap; więcej czasu na dojście do "bold + listy + screenshoty" niż potrzeba.
- **Editor.js** - blokowy z założenia, ale to osobny format JSON i inny model mentalny niż typowy rich text; sensowny gdy od początku chcesz strukturę blokową, mniej gdy chcesz szybko dowieźć klasyczny WYSIWYG.

**Dlaczego Tiptap wygrywa dla tego przypadku:**
- Oparty na ProseMirror, więc masz solidny, sprawdzony w produkcji silnik dokumentu (ten sam co w Notion czy Linear) bez pisania go samemu.
- Bold, listy, wklejanie obrazków/screenshotów (`handlePaste`) i toolbar dostajesz z gotowych rozszerzeń w ciągu dnia-dwóch, nie tygodnia.
- Model "custom block = własne `Node` rozszerzenie" jest udokumentowany i jest to dokładnie ta ścieżka rozbudowy, o której piszesz ("extend later with custom blocks") - nie trzeba tego dorabiać na siłę później.
- Aktywnie rozwijany, dobra dokumentacja, spore community - mniej ryzyka, że utkniesz na czymś niszowym pod presją czasu.

Główny kompromis: Tiptap/ProseMirror ma bardziej stromą krzywą uczenia niż Quill, jeśli ktoś w zespole będzie majstrował głębiej w schemacie dokumentu - ale na start (bold, listy, obrazki) to nieodczuwalne, a płaci się to później i tak przy każdym z tych wyborów.

Wziąłbym **Tiptap** (na ProseMirror) - ma gotowe, dobrze udokumentowane rozszerzenia na pogrubienie, listy i wklejanie obrazków, a system Node/Mark extensions jest wprost zaprojektowany pod własne bloki, więc dopisanie ich później nie wymaga przepisywania rdzenia edytora.

Rozważałem jeszcze **Lexical** (Meta) - solidniejszy pod względem wydajności i modelu dokumentu, ale młodszy ekosystem i więcej boilerplate'u przy własnych node'ach - oraz **Slate**, które daje pełną kontrolę, ale historycznie ma niestabilne API i sporo trzeba zbudować samemu (undo/redo, skróty markdown, obsługa wklejania). **Editor.js** odpadł, bo to raczej block-based edytor JSON niż inline WYSIWYG - gorzej pasuje do zwykłego "zaznacz i pogrub", którego oczekują wasi agenci supportu.

Główny kompromis: Tiptap jest headless, więc UI (toolbar, formatowanie) budujecie sami - ale to akurat pasuje, bo i tak chcecie go dopasować do własnego designu i rozszerzać o custom bloki.

Wybrałbym **TipTap** (na ProseMirrorze).

**Dlaczego TipTap:**
- `StarterKit` daje bold, listy, nagłówki od ręki, więc pogodzisz się z terminem "w tym tygodniu" bez pisania edytora od zera.
- Wklejanie zrzutów ekranu to gotowe rozszerzenie (`Image` + obsługa paste/drop) - support agenci wkleją screen ze schowka i po sprawie.
- Model rozszerzeń (custom Node/Mark/Extension) jest dokładnie tym, czego potrzebujesz do własnych bloków później - to nie hack na końcu API, tylko główny sposób, w jaki się z TipTapem pracuje.
- Duża społeczność, aktywny rozwój, dużo gotowych przykładów integracji z React (hooki, kontrolowany stan, SSR).

**Co jeszcze rozważałem:**
- **Lexical** (Meta) - realna alternatywa, technicznie bardzo solidna i wydajna, też ma dobry model węzłów pod custom bloki. Odpadł głównie przez czas: mniej gotowych "z pudełka" rzeczy (wklejanie obrazków, listy) trzeba doklejać samemu, dokumentacja i ekosystem wciąż węższe niż TipTap/ProseMirror. Wróciłbym do niego, gdyby priorytetem była wydajność na bardzo dużych dokumentach albo collaborative editing na dużą skalę.
- **Slate** - odrzucony. Elastyczny w teorii, ale API historycznie niestabilne między wersjami i mnóstwo edge case'ów (selection, IME, undo) trzeba łatać samemu. Zbyt duże ryzyko przy terminie tygodnia.
- **Quill** - szybki start, ale model danych (Delta) słabo się nadaje pod custom bloki, których chcecie dokładać później. Dobry do "prostego edytora na zawsze", zły do "prosty teraz, rozbudowany potem".
- **Editor.js** - koncepcyjnie blokowy, czyli pasuje do "custom blocks", ale integracja z React jest bardziej DIY, a społeczność i tempo rozwoju mniejsze niż TipTapa.

Rozstrzygnęło połączenie: szybki start w tydzień + solidny, długoterminowy model rozszerzeń pod custom bloki. To dwie sprzeczne potrzeby naraz i TipTap jest jedynym z tej listy, który dobrze spełnia obie równocześnie.

Rekomendacja: **Tiptap** (nakładka na ProseMirror).

Dlaczego on:
- Model dokumentu oparty na schemacie (węzły/marki) to naturalne miejsce na własne bloki później - dodajesz nowy `Node` z własnym React NodeView, nie przepisujesz edytora.
- Ekosystem jest gotowy do użycia w tydzień: gotowe rozszerzenia na bold/listy, wklejanie obrazów (`handlePaste` + upload), tabele, wklejanie z Worda/Google Docs bez śmieciowego HTML.
- Duża baza produkcyjna i dokumentacja - mniej ryzyka, że utkniesz na czymś banalnym w piątek przed deadline'em.

Co jeszcze rozważałem i dlaczego odpadło:
- **Lexical** (Meta) - architektura jest bardzo czysta i wydajna, i długoterminowo pewnie dogoni Tiptap, ale ekosystem gotowych rozszerzeń (upload obrazków, konwertery) jest chudszy, więc więcej klejenia własnoręcznie. Przy presji "ten tydzień" to koszt, którego bym nie brał.
- **Slate** - najbardziej elastyczny, ale to bardziej framework do budowania edytora niż edytor. Toolbar, obsługa list, paste handling - wszystko piszesz sam. Dobry wybór, gdybyś miał miesiąc i bardzo specyficzne wymagania, nie tydzień.
- **Editor.js** - blokowy, ładny JSON na wyjściu, ale to bardziej "block builder" (jak Notion) niż inline rich text. Formatowanie w locie (bold w środku zdania, mieszane listy) jest tam mniej naturalne niż w Tiptap/Slate.
- **Quill** - najszybszy do wdrożenia, ale to zamknięty model dokumentu (Delta), rozszerzanie o własne bloki jest dużo bardziej bolesne niż w Tiptap. Dobry na "potrzebuję tylko bold i listy i tyle", zły na "będziemy to rozwijać".

Główny kompromis: Tiptap kosztuje trochę więcej boilerplate'u na starcie niż Quill, ale to jedyny z tej listy, gdzie "custom blocki później" nie oznacza przepisywania edytora od zera.

Wybrałbym **Tiptap** (na ProseMirror) - ma oficjalne bindingi do Reacta, dojrzały model dokumentu, prosty format rozszerzania o własne node'y/bloki (dokładnie pod "custom blocks" na później) i gotowe wzorce na wklejanie obrazków ze schowka. To pozwala ruszyć w tydzień, a jednocześnie nie zamyka drogi rozwoju.

Główny kompromis: **Lexical** (Meta) jest lżejszy i też dobrze się rozszerza, ale ekosystem i dokumentacja są młodsze, więc mniej gotowych przepisów na typowe problemy (wklejanie, drag&drop obrazków) - oszczędzasz na starcie, płacisz później researchem. **Editor.js** odpadł, bo jego model blokowy pasuje do "custom blocks", ale integracja z Reactem jest nakładką na czysty JS, nie pierwszej klasy.

Czy mam rozpisać plan integracji Tiptapa w Waszej apce (upload/paste obrazków, toolbar, zapis do backendu), czy najpierw chcesz POC na konkretnym komponencie?