UX Patterns Guide
UI + UX Input And Data Entry established

Inline edit

Let a displayed value, table cell, or row switch into a local edit control with a clear edit trigger, Save and Cancel, contextual validation, dirty-state protection, and table refresh or sort behavior that keeps the edited item understandable.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • Users frequently update one visible value or one row property.
  • Surrounding table, list, or details-page context helps the edit.
  • The change is low-impact and can be saved or canceled independently.
  • The product can preserve original value, draft value, validation state, and failed-save recovery.

Avoid when

  • The edit affects multiple dependent fields or needs a review step.
  • The value is high-risk, irreversible, bulk-applied, or permission-sensitive.
  • The displayed value already functions as a link, drill-down target, row selector, or copyable text region.
  • The table cannot handle sorting, filtering, pagination, refresh, or one-row edit state predictably.
  • The platform cannot provide accessible edit, save, cancel, and validation controls in the available space.

Problem it prevents

Small edits become slow or risky when users must open a separate form for one visible value, or when in-place editing hides whether the value is read-only, changed, saved, invalid, or cancelable.

Pattern anatomy

What a strong implementation has to make clear

User need

The user is viewing a record, list, table, or details page and needs to update one low-impact property.

Pattern promise

Let a displayed value, table cell, or row switch into a local edit control with a clear edit trigger, Save and Cancel, contextual validation, dirty-state protection, and table refresh or sort behavior that keeps the edited item understandable.

Required state

Read state with displayed value and discoverable edit affordance.

Recovery path

The edit affordance appears only on pointer hover and is unreachable by keyboard or touch.

Access contract

Give edit, save, cancel, confirm, and dismiss controls accessible names, especially when icons are used.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • A resource table shows an edit icon beside the owner cell; activating it turns that cell into a text field with Save and Cancel buttons while other cells remain read-only.
  • A details page shows a visible Edit label next to an editable display name and keeps non-editable fields as plain read-only values.
  • A user clicks Edit owner, changes the value, sees Save become enabled, enters an invalid short value, fixes it beside the field, saves, and stays on the same row.
  • A user starts editing a table cell, clicks another row, sees a dirty-change warning, discards the draft, and the original value is restored.
Weak implementation

Vague, hidden, hard to recover from

  • Every table cell is always an input, so users cannot tell which values changed or whether a row is still just being read.
  • A displayed value becomes editable only when users click the text, but there is no edit affordance, no cancel button, and no saved state.
  • A user types a new value and clicks elsewhere; the product silently discards the draft with no warning.
  • A user edits a sorted table cell and the row immediately jumps to a different page before the saved value can be confirmed.
UI guidance
  • Render a read-state value with a visible edit affordance, then replace only that value, cell, or row with the appropriate input and adjacent Save and Cancel controls when edit mode starts.
  • Show text states for editable, editing, changed, validation error, saving, saved, and read-only values; do not rely on hover or color alone to reveal editability.
UX guidance
  • Use inline edit when users need to make frequent, low-impact changes to one visible property while preserving surrounding list, table, or record context.
  • Keep the edit local: disable save until the draft differs from the original, validate beside the input, preserve the original for cancel, and protect unsaved changes when users click away or navigate.
Implementation contract

What the implementation must handle

States

  • Read state with displayed value and discoverable edit affordance.
  • Read-only or unavailable state for values that cannot be edited.
  • Edit mode with focused input and adjacent Save and Cancel controls.
  • Unchanged draft state where Save is disabled or explained.

Interaction

  • Edit changes only the targeted value, cell, or row into edit mode and leaves unrelated content in read mode.
  • Only one table row or one conflicting edit scope can be active at a time unless the product explicitly supports batch editing.
  • Save commits the changed draft, reports validation errors in place, and returns to read mode only after success.
  • Cancel discards the draft and restores the original displayed value.

Accessibility

  • Give edit, save, cancel, confirm, and dismiss controls accessible names, especially when icons are used.
  • Do not rely on hover alone to reveal editability; keyboard and touch users need a visible or focus-revealed affordance.
  • Move focus into the edited input when edit mode starts and return focus to the edited value or edit trigger after save or cancel.
  • Announce validation errors beside the edited input and associate them with the control.

Review

  • Is the edit low-impact enough to commit locally without broader review?
  • Can users discover which values are editable before clicking them?
  • What happens to the original value if the user cancels or clicks away?
  • Does Save stay disabled until a real change exists?
Interactive lab

Inspect the states before you copy the pattern

Edit one displayed value in place

Enter edit mode, change the value, test validation, cancel, click away with a dirty draft, and save without leaving the row.

Inline edit
Interactive demo is ready

Launch the live UI/UX lab when you want to inspect states, keyboard behavior, and common failure modes.

State To Inspect

Read state with displayed value and discoverable edit affordance.

Keyboard / Access

Tab reaches the edit trigger for editable values and skips values that are genuinely not editable.

Avoid Generating

Using inline edit for high-impact changes that need a review or confirmation step.
Evidence trail

Source-backed claims behind this guidance

Cloudscape Design System: Inline edit

Cloudscape Design System - checked

Cloudscape supports inline editing for frequently updated resource properties and table cells, including editable indicators, confirm/dismiss actions, validation, refresh, and sorting behavior.

PatternFly: Inline Edit

PatternFly - checked

PatternFly supports save/cancel controls, disabled save until a change exists, one-row editing, dirty click-away confirmation, validation, and restrictions around drill-down and bulk edit.

Full agent/debug reference

Problem Context

  • The user is viewing a record, list, table, or details page and needs to update one low-impact property.
  • Keeping surrounding context visible helps the user choose the right value or compare rows.
  • The edit can be committed or canceled independently without reviewing a larger form.
  • The system can preserve the original value and reliably report save, validation, and failed-save states.

Selection Rules

  • Choose inline edit for frequent low-impact edits to one displayed value, table cell, table row, or resource property.
  • Use text input instead when the user is already inside a normal form and there is no separate read state.
  • Use single-page form when several related values should be reviewed and submitted together.
  • Use modal dialog when a short edit needs focused explanation or secondary controls but should not become a whole page.
  • Use complete complex form when changes span sections, dependencies, or review-before-save consequences.
  • Do not use inline edit for irreversible, high-impact, bulk, or cross-record changes without stronger confirmation or review.
  • Avoid inline edit where clicking a value already opens drill-down, selects text, expands a row, or triggers row selection.
  • In tables, account for sort, filter, pagination, refresh, row selection, and one-row-at-a-time editing before enabling inline edit.
  • Make editability visible through an edit button, icon, hover affordance, or row action with an accessible name.
  • Keep Save disabled or clearly unavailable until the draft differs from the original value.

Required States

  • Read state with displayed value and discoverable edit affordance.
  • Read-only or unavailable state for values that cannot be edited.
  • Edit mode with focused input and adjacent Save and Cancel controls.
  • Unchanged draft state where Save is disabled or explained.
  • Dirty draft state where Save is available and Cancel restores the original value.
  • Validation error state shown beside the edited input.
  • Dirty click-away or navigation state that asks whether to save, discard, or keep editing.
  • Saving state that prevents duplicate commit without losing the draft.
  • Saved success state that returns to read mode with the new value visible.
  • Failed-save state that keeps the input editable and reports recovery.

Interaction Contract

  • Edit changes only the targeted value, cell, or row into edit mode and leaves unrelated content in read mode.
  • Only one table row or one conflicting edit scope can be active at a time unless the product explicitly supports batch editing.
  • Save commits the changed draft, reports validation errors in place, and returns to read mode only after success.
  • Cancel discards the draft and restores the original displayed value.
  • Click-away with no changes can exit edit mode; click-away with changes must save, discard, or keep editing by explicit user choice.
  • Sorting, filtering, pagination, and refresh should not make the edited item disappear before users can understand the saved result.
  • Keyboard users can enter edit mode, move through editable fields, save, cancel, and recover from errors without relying on hover.

Implementation Checklist

  • Identify which values are editable and which are read-only before adding edit affordances.
  • Give every edit trigger and icon-only Save or Cancel control an accessible name.
  • Store the original value separately from the draft so Cancel and dirty comparison are reliable.
  • Disable Save until the draft differs from the original, or explain why save is unavailable.
  • Place validation messages directly beside the edited input and keep the draft editable after errors.
  • Implement dirty click-away and route-change handling before enabling inline edit in dense tables.
  • Decide how active sort, filter, pagination, and refresh behave after a value changes.
  • Prevent conflicts with row drill-down, row selection, text selection, bulk actions, and keyboard shortcuts.
  • Test keyboard entry, Escape or Cancel, Enter or Save, focus return, screen reader labels, validation, failed save, and mobile hit targets.

Common Generated-UI Mistakes

  • Using inline edit for high-impact changes that need a review or confirmation step.
  • Making static text secretly editable with no visible affordance.
  • Removing Cancel, so users cannot restore the original value.
  • Saving every keystroke while presenting the interaction as explicit save/cancel inline edit.
  • Letting sorted or filtered rows jump away immediately after the value changes.
  • Allowing multiple table rows to enter edit mode when row selection and bulk actions are still active.
  • Using inline edit for a large multi-field form that belongs in a page, modal, or complex form.
  • Replacing text with an input on hover and blocking users from selecting or copying the displayed text.

Critique Questions

  • Is the edit low-impact enough to commit locally without broader review?
  • Can users discover which values are editable before clicking them?
  • What happens to the original value if the user cancels or clicks away?
  • Does Save stay disabled until a real change exists?
  • Where does validation appear and can users fix it in place?
  • Will sorting, filtering, pagination, row selection, or drill-down conflict with edit mode?
Accessibility
  • Give edit, save, cancel, confirm, and dismiss controls accessible names, especially when icons are used.
  • Do not rely on hover alone to reveal editability; keyboard and touch users need a visible or focus-revealed affordance.
  • Move focus into the edited input when edit mode starts and return focus to the edited value or edit trigger after save or cancel.
  • Announce validation errors beside the edited input and associate them with the control.
  • Expose changed, saving, saved, failed, and read-only states in text or status regions.
  • Preserve text selection behavior when clicking or dragging displayed text should select rather than edit.
  • Keep table row and cell semantics understandable when a row switches into edit mode.
Keyboard Behavior
  • Tab reaches the edit trigger for editable values and skips values that are genuinely not editable.
  • Enter or Space activates the edit trigger and moves focus to the input.
  • Tab moves through editable fields, Save, Cancel, and any dirty-warning actions in a predictable order.
  • Escape can cancel edit mode only if it follows the same discard contract as Cancel.
  • Enter can save single-line inline edits when this does not conflict with input semantics.
  • After validation fails, focus stays on or returns to the invalid inline input.
  • After save or cancel, focus returns to the edited value or the control that opened edit mode.
Variants
  • Inline text edit
  • Inline editable table cell
  • Inline editable row
  • Inline select edit
  • Inline textarea edit
  • Inline create row
  • Inline edit with dirty confirmation
  • Inline edit with optimistic save
  • Inline edit with server validation
  • Inline edit in resource details

Verification

Last verified: