---
title: Confirmation vs Undo
slug: confirmation-vs-undo
kind: decision
summary: Whether an action should ask "are you sure" or just happen with a way back. The answer is decided by reversibility and blast radius, not by how dangerous the verb sounds.
problem: >-
  Confirmation gets applied by feel, so it lands on the wrong actions — a dialog
  on archiving one item that someone does forty times a day, and none on the
  bulk delete that cannot be undone. Once everything is confirmed, people click
  through confirmations without reading, and the protection is gone anyway.
family: [act, recover]
data_shape: [record]
principles: [friction, orientation]
interaction: [decision]
density: low
complexity: low
status: stable
visibility: public
use_when:
  - You are adding a destructive or hard-to-reverse action.
  - An existing screen confirms everything, or nothing.
  - People report both "too many pop-ups" and "I lost work" about the same product.
avoid_when:
  - The action is a pure navigation or a read. Neither mechanism applies.
alternatives:
  - slug: review-queue
    when: The action repeats hundreds of times a day — that volume settles the question by itself.
  - slug: unsaved-changes-guard
    when: The risk is losing work in progress rather than performing an action.
ask_leo: |
  Decide per action whether it confirms or offers undo, and apply the rule
  consistently across this app.

  If the action is reversible and affects one record, do it immediately and show
  a brief message with an Undo control. Keep the undo available for at least ten
  seconds, and make undo restore the exact previous state, not an approximation.

  If the action is irreversible, or affects many records at once, or is visible
  to someone outside the company — sending an email, issuing a refund, deleting
  a customer — confirm first. The confirmation must name what will happen and
  how much: "Delete 43 invoices? This cannot be undone." Never a bare "Are you
  sure?".

  For the most severe irreversible actions, require the person to type the name
  of the thing being destroyed.

  Do not confirm an action that people perform many times a day. If it is
  frequent AND irreversible, make it reversible instead — that is the real fix.

  Never show two confirmations in a row for one intent.
related:
  - title: Review Queue
    url: /patterns/review-queue
    summary: The clearest case where undo beats confirmation, because the action repeats all day.
  - title: Eliminating friction
    url: /patterns/friction
    summary: Why a confirmation is a tax charged to everyone to protect against a few.
---

## The decision

Take the first row that matches.

| If this is true | Use | Because |
|---|---|---|
| The effect leaves your system — an email sent, a payment taken, a webhook fired | **Confirm** | Nothing you build can recall it |
| The action is irreversible in the data | **Confirm**, and name the count | Undo would be a lie |
| It affects many records at once | **Confirm**, and name the count | The blast radius is the risk, not the verb |
| It happens many times a day | **Undo** | A dialog here costs more than the mistakes it prevents |
| It is reversible and affects one record | **Undo** | Cheaper, safer, and does not train click-through |
| None of the above | **Undo** | The safer default: it protects without taxing |

Two things are deliberately absent from that table: how destructive the verb
*sounds*, and how nervous the person who requested the feature feels. "Archive"
sounds gentle and "Delete" sounds severe, but if archive is irreversible and
delete is a soft flag, the correct treatments are the other way round.

## Why undo is usually the better instrument

A confirmation dialog charges **every** user on **every** invocation to protect
against a mistake **some** users make **occasionally**. Undo charges nothing up
front and pays out only when needed.

It is also more honest about how people work. Nobody reads the fifth identical
confirmation, so confirmation on frequent actions does not prevent errors — it
converts them into errors made slightly later, after a reflexive click. The
dialog produces the feeling of safety without the fact of it.

## When confirmation genuinely wins

**Irreversibility is the real trigger.** If you cannot offer undo, you owe the
person a moment of attention instead — and the way to spend it well is
specificity: what, how many, and that it cannot be taken back.

**Blast radius is the second.** One archived record is a mistake; forty deleted
invoices is an incident. Bulk actions deserve confirmation even when a single
one does not, which means the same verb can be correct both ways in one product.

**Leaving the system is the third.** A sent email cannot be unsent. A short
send-delay window is a real alternative here — it is undo, implemented as a
delay — and it is usually better than a dialog.

## Making undo real

The failure mode of undo is that it is approximate. If undoing a delete restores
the record but drops its attachments, or restores it at the bottom of a list
instead of its original position, people learn not to rely on it, and you now
have neither mechanism.

- Restore the exact previous state, including position and related records.
- Keep the affordance visible long enough to be used — ten seconds is a common
  floor, longer for bulk actions.
- Say what happened. "Archived" alone is not enough; "Invoice INV-1041
  archived" is.
- Put the undo in the same place every time, so it is a habit rather than a
  hunt.

## Getting it wrong

- **"Are you sure?"** — the least useful sentence in software. Sure about what,
  affecting how much?
- **Confirming everything**, which trains click-through and removes the
  protection from the actions that needed it.
- **Undo on something irreversible**, which is a promise the system cannot keep.
- **Two dialogs for one intent**, which reads as the software not knowing what
  it wants.
- **A toast that disappears in two seconds**, which is decoration, not recovery.

## Exemplars

**Gmail's undo send** is the strongest example in consumer software: the action
genuinely leaves the system, and rather than adding a dialog they added a delay
and made undo possible. That is the move worth stealing — change the
reversibility instead of adding friction.

**GitHub's repository deletion** shows the other end done properly: type the
repository name to proceed. Irreversible, high blast radius, rare — exactly the
regime where a confirmation should be *harder*, not softer.

**macOS Finder** trashes rather than deletes, which converts nearly every
destructive file action into a reversible one. Most confirmation debates
disappear once someone asks whether the action could simply be made reversible.

The extractable rule: **confirmation and undo are not two styles, they are two
answers to one question — can this be taken back?** Answer that first, and the
interface follows.