HTML contenteditable versus textarea: choose the data model first

Use it for a real task

A receipt reviewer needs a short plain-text reason. Textarea submits its value with the form and has established keyboard and label behavior. A rich document editor might justify contenteditable, but then the application must handle focus, selection, paste, serialization, sanitization, and storage. That is a separate product feature, not a style change to an existing field.

<form action="/receipts/R-47/reason" method="post">
  <label for="reason">Reason for hold</label>
  <textarea id="reason" name="reason" maxlength="240" required></textarea>
  <button type="submit">Save reason</button>
</form>
<p contenteditable="true" spellcheck="true">Scratch notes are not submitted by this form.</p>

What the markup guarantees

The editable paragraph is only a demonstration of the difference; without explicit application code, its changes are neither persisted nor sent to the endpoint. Avoid presenting such an area as a real saved note.

Cost and limits

Textarea keeps the interaction small. A rich editor adds code, sanitation policy, and security review, with cost proportional to document size and supported editing operations.

Common Mistakes

• Do not assume contenteditable contributes a name/value pair.
• Do not store pasted HTML without a defined trust boundary.
• Do not replace a plain-text field with a rich editor without a need.

Connected lessons

• HTML labels: bind each control to a durable accessible name
• HTML select and textarea: preserve meaningful values and editable text
• HTML character references: escape data before inserting it into markup

Related CSS decisions

• CSS text-wrap: pretty: spend line-breaking work where copy merits it