Inline Editing

Last updated:

Practical patterns for in-place edits with explicit save, cancel, and escape behaviour.

01 — Foundation

Inline edit must be escapable

Editing in place saves clicks only when save, cancel, and errors are obvious.

Inline editing lets users change a value without navigating away — titles, table cells, settings. It fails when users cannot tell they are in edit mode, lose work on accidental blur, or get trapped without keyboard escape.

02 — Controls

Enter edit mode deliberately

A clear trigger, explicit save and cancel, and predictable keyboard behaviour.

  • “Edit” button or labelled control — not mystery double-click only
  • Save and Cancel visible — Enter to save only when that matches user expectation
  • Escape cancels and restores the previous value
  • show saving and error state — see Save States and Async Actions

03 — Implementation

Inputs over contenteditable alone

Prefer real form controls with labels and validation.

  • use input or textarea with associated labels
  • contenteditable only with great care — paste, validation, and AT support are harder
  • validate on save; show errors next to the field — see Accessible Forms 
<form>
    <label for="project-name">Project name</label>
    <input id="project-name" name="name" value="Q1 Report" />
    <button type="submit">Save</button>
    <button type="button">Cancel</button>
</form>

04 — Review

Before you approve

A short checklist for inline editing in code review.

  • edit mode is obvious; cancel and save are explicit
  • Escape and focus behaviour tested; errors are specific
  • undo considered for destructive inline changes — see Undo and Restore