contentEditable vs Textarea: Getting a Rich Chat Input Without a Heavyweight Editor

Every team that builds a chat product eventually hits the same fork in the road. You need an input box that does a little more than a plain <textarea>. It should hold @mentions as solid pills, recognize a / command, maybe render a URL as a link. So you reach for the tool you already know: a real editor framework like Tiptap, Lexical, or Slate. A week later you're fighting schema nodes and serialization just to make Enter submit a message. The mismatch isn't your fault. It's that a chat composer and a document editor are different problems wearing similar clothes.

This piece walks through the actual tradeoffs between the three options (a textarea, raw contentEditable, and a full editor framework) and where each one earns its place. I'll be fair to the heavy editors, because they're genuinely good at what they're built for. They're just usually the wrong job for a prompt box.

The three options, honestly compared

The plain textarea

A <textarea> is the floor, and it's a high floor. It's accessible by default, handles IME composition for CJK input without you thinking about it, supports native undo/redo, and never surprises you with a weird selection bug. If your input is genuinely just plain text, such as a search box, a comment field, or a basic message, start here and don't apologize for it.

The wall you hit is rich content. A textarea cannot render anything inside itself. You can't show a blue @alice pill, you can't bold a word inline, you can't make a URL clickable while the user is still typing. People work around this with an overlay div positioned pixel-perfect behind the textarea, mirroring its content with styled spans. It works until it doesn't: caret math drifts, line wrapping disagrees, and you've quietly built a worse editor than the one you were avoiding.

The full editor framework

Tiptap, Lexical, Slate, ProseMirror, Plate, and BlockNote are document editors. They model content as a tree of nodes with a schema, give you collaborative editing, tables, nested blocks, and a plugin system deep enough to rebuild Notion. That depth is real engineering value when you're building a document editor.

For a chat input, that same depth is mostly a tax. You inherit two to five extra dependencies, a bundle that dwarfs your message box, and an abstraction layer you have to learn before you can do anything. Worse, the defaults fight you: a document editor wants Enter to make a new paragraph, but a chat composer wants Enter to send and Shift+Enter to make a newline. You wanted a feature, and you got a framework. When people go looking for Tiptap alternatives or Lexical alternatives for a chat box, what they usually want is something that solves the same surface problem with far less ceremony.

Raw contentEditable

The third option is the one everyone fears: a bare contentEditable div, and the fear is earned. contentEditable React work is notorious because React's controlled-input model and the browser's live DOM editing fundamentally disagree. React wants to own the DOM; contentEditable lets the browser mutate it from under you. Re-render at the wrong moment and the caret jumps to the start. Paste from Word and you get a soup of inline styles. Selection handling across browsers is a minefield.

But here's the thing: contentEditable is also the only primitive that can natively render a real DOM node, a styled non-editable chip, inline with editable text, with a real caret flowing around it. That's exactly what a chat composer needs. The problem was never the primitive. It was that nobody wants to solve the same dozen caret, selection, and paste bugs from scratch on every project.

Why a purpose-built input is the missing middle

This is the gap Prompt Area was built to fill. It's a production-grade contentEditable rich text input aimed squarely at prompt-style and chat composer use cases, the ChatGPT, Claude, Linear, and Slack-style boxes, and deliberately not a document editor. The pitch is plain: most rich editors are full document frameworks shoehorned into chat inputs, so Prompt Area starts from the input instead.

Concretely, that means it solves the hard contentEditable problems for you so you don't relive them:

• Cursor and selection management: the caret stays put across React re-renders, and selection behaves consistently across browsers.
• Immutable chip pills: resolved mentions, slash commands, and tags render as non-editable chips you can't accidentally type into the middle of.
• IME support: proper composition handling so CJK input doesn't fire premature events or eat characters.
• Chip-preserving copy/paste: copy a message with chips and paste it back in, the chips survive; paste raw text from outside and triggers auto-resolve.

It also covers the rest of the chat-input checklist: trigger-based dropdowns on @, /, # or any character, inline markdown preview for **bold** and *italic*, URL auto-linking, list auto-formatting, undo/redo with debounced snapshots, auto-grow on focus, file and image attachments, and rotating placeholders. The surface area stays tiny: one component, PromptArea, and one hook, usePromptAreaState().

The detail that matters most for the comparison: zero extra dependencies. No ProseMirror, no Slate, no Lexical underneath, just React and your existing stack. And it ships two ways from one source. You can install it from npm, where it brings a self-contained styles.css that needs no Tailwind (with an optional Tailwind preset if you want token theming), or you can pull the source into your repo through the shadcn registry and own the code outright.

// npm: ships its own styles.css, no Tailwind required npm install prompt-area // or via the shadcn registry, which copies the source into your repo npx shadcn@latest add https://prompt-area.com/r/prompt-area.json

The data model: simpler than a document tree

The clearest way to see why a chat input doesn't need a document framework is to look at how it models content. A document editor needs a recursive node tree to represent nested blocks, marks, and structure. A chat composer doesn't. Its content is essentially a flat sequence: some text, a chip, more text, another chip. Prompt Area models exactly that: its controlled value is a Segment[] array, where each segment is either text or a chip.

type Segment = TextSegment | ChipSegment interface TextSegment { type: 'text' text: string } interface ChipSegment { type: 'chip' trigger: string // '@', '/', '#', ... value: string // the resolved id/value displayText: string // what the pill shows data?: unknown // anything you attach autoResolved?: boolean // came from pasted text } // A message like: Hey @alice run /deploy const value: Segment[] = [ { type: 'text', text: 'Hey ' }, { type: 'chip', trigger: '@', value: 'u_123', displayText: 'alice' }, { type: 'text', text: ' run ' }, { type: 'chip', trigger: '/', value: 'deploy', displayText: 'deploy' }, ]

That flat shape is the whole point. You can read it, diff it, and serialize it without a framework's help. Need the prompt as a string for an API call? segmentsToPlainText(value). Need every mention you collected? getChipsByTrigger(value, '@') hands you the structured chips so you can send real ids in a request body instead of regex-parsing a string on the server. Companion helpers like plainTextToSegments, isSegmentsEmpty, and hasChips round it out, and usePromptAreaState() gives you the controlled state with zero setup. Compared to walking a ProseMirror document node tree to answer the same question, it's a different category of effort.

So which should you pick?

Let the content decide, not the habit:

1. Genuinely plain text? Use a <textarea> (or a thin auto-size wrapper). Don't over-build.
2. Long-form structured documents with nested blocks, tables, and collaboration? Use a real editor framework. This is what Tiptap, Lexical, Slate, and ProseMirror are for, and they earn their dependencies.
3. A chat or prompt composer with mentions, slash commands, inline markdown, attachments, and send-on-Enter? Reach for a purpose-built input like Prompt Area. You get the chip-and-caret power of contentEditable without paying the document-framework tax, and without rediscovering the IME and paste bugs yourself.

The instinct to "just use the editor we already know" is understandable, but a chat composer is a constrained, well-defined problem. It deserves a tool shaped like the problem rather than a document editor bent into the role. Picking the right primitive, and letting something like Prompt Area absorb the gnarly contentEditable details, is usually the difference between a message box you ship in an afternoon and one you're still debugging the caret on three weeks later.