How Undo Works, And Why It Sometimes Cannot

Undo feels like a fundamental property of software, but it has to be built by hand for every action. The actions that lack it reveal how the mechanism works.

The program records intentions, not results

Rather than storing the document repeatedly, applications store a list of operations. Each entry describes what was done and carries enough information to reverse it.

Deleting a paragraph records the text removed and its position. Reversing that entry means reinserting exactly that text in exactly that place.

The list is a stack. Undo pops the most recent entry and applies its inverse, while redo pushes it back and reapplies the original.

Some operations have no inverse

An operation is reversible only if the information it destroyed was preserved. Reducing an image's resolution discards detail that cannot be reconstructed from the result.

The usual answer is to keep a copy of the affected region before the change. This is why memory-hungry operations often have a shorter undo history.

Applications that work non-destructively sidestep this entirely by storing the original and a list of adjustments, then computing the visible result each time.

Effects outside the program cannot be recalled

Saving a file, sending a message or printing a page changes something the application no longer controls. There is nothing to reverse.

Interfaces that appear to undo these actions are usually delaying them. A message shown as sent may be sitting in a queue for a few seconds.

Once the delay elapses the option disappears, which is why such undo windows are brief and cannot be extended. The action genuinely left.

Grouping is a judgement call

Recording every keystroke separately would make undo useless, so applications merge consecutive similar actions into one entry.

The boundaries are heuristics: a pause in typing, a change of location, a different kind of edit. They are guesses about what the user considers a single action.

When undo removes far more or far less than expected, the grouping rule and the user's mental model have diverged. Neither is wrong, they were never negotiated.

Shared documents break the stack

With several people editing at once, the most recent change may not be yours, and reversing it would undo someone else's work.

Collaborative systems therefore maintain per-user histories and must transform each reversal against everything that happened since, so it still makes sense in the current document.

This is genuinely difficult, and it is why undo in shared documents occasionally produces a result that is defensible in the algorithm and surprising to everyone watching.