If you've ever hammered Ctrl+Z in a panic — trying to claw back a paragraph you deleted, a formatting change that went wrong, or a file you accidentally overwrote — and hit an invisible wall after a certain number of presses, you know the frustration. The undo history just… stops. Whatever happened before that point is gone, and no amount of keyboard shortcuts will bring it back.
What's stranger is that the limit isn't always the same. Some apps give you 20 steps. Some give you 100. Some seem to forget everything the moment you close and reopen a file. It feels arbitrary, almost capricious — like the software is deciding on your behalf how many mistakes you're allowed to regret.
But the limit isn't arbitrary at all. It's the product of specific engineering decisions, hardware constraints that date back decades, and a surprisingly rich design history. Understanding why undo has a ceiling — and why that ceiling is often set at exactly 20 — makes the whole thing feel a lot less like a punishment and a lot more like a reasonable trade-off.
An all-in-one Notion life planner for habits, goals, to-dos, wellbeing and money, in one calm dashboard.
The Memory Cost of Remembering Every Single Change
Every time you make a change in a document, image, or spreadsheet, the software has to store a snapshot — or at least a record of the difference — so it can reverse that action later. This is called the undo stack. Each entry on that stack takes up memory. For a simple text edit, that cost is tiny. For a high-resolution photo filter applied in Photoshop, it can be enormous — sometimes hundreds of megabytes per step.
If an application kept an unlimited undo history, it would eventually consume all available RAM. On the computers of the 1980s and early 1990s, where RAM was measured in kilobytes, even a 20-step limit was considered generous. Engineers had to make a deliberate choice: how many steps of history are actually useful before the user either saves their work or accepts the current state? The answer, arrived at through testing and convention, was roughly 20.
Even today, when computers have gigabytes of RAM, the limit persists in many applications because the logic still holds. An unlimited undo history for a complex document can silently balloon a program's memory footprint, slowing everything else down. The cap is less about punishing users and more about keeping the rest of the system — and the app itself — responsive and stable.
How the Undo Command Got Its 20-Step Default in the First Place
The undo command as we know it was formalized by Warren Teitelman at Xerox PARC in the early 1970s as part of the Interlisp programming environment. He called the concept "Do What I Mean" (DWIM), and it included the ability to reverse recent commands. The idea was radical for its time: instead of treating every action as permanent, the computer would maintain a short memory of what you'd done.
When Apple introduced the Mac in 1984 and included Undo in its Human Interface Guidelines, the command became standardized across consumer software. Apple's guidelines recommended a single level of undo at first — just one step back. Multi-level undo, the kind that lets you step back through a whole sequence of actions, became common in the late 1980s and early 1990s as RAM became cheaper and more plentiful.
The 20-step default that many applications adopted wasn't handed down from a single authority. It emerged from a confluence of practical testing and convention. Microsoft Word, for instance, used a relatively shallow undo history in its early versions and expanded it over time. Adobe products, dealing with much heavier per-step memory costs, often defaulted to 20 history states as a compromise between usability and performance. Twenty felt like enough for most workflows without being reckless with resources — and once it became the norm, it stuck, much the same way that certain conventions in email signatures became standard simply by being widely adopted first.
Why Apps Don't Just Make Undo Unlimited by Default
The most obvious question is: why not just let users undo forever? Storage is cheap, RAM is plentiful, and modern SSDs can handle large amounts of data quickly. The answer is that undo history isn't stored on disk like a file — it lives in active memory, ready to be accessed instantly. Storing hundreds of states for a complex project in RAM is a very different proposition from storing a finished file on a hard drive.
There's also the question of what counts as a single "step." In a word processor, each keystroke could theoretically be its own undoable action. If you typed a 500-word paragraph and every character was a separate undo step, you'd need 2,500 presses of Ctrl+Z just to get back to a blank page. Most applications solve this by grouping actions — treating a whole word, or a whole formatting change, as one step — but this grouping logic itself takes engineering effort and introduces its own edge cases.
Some modern applications, like Figma and Google Docs, have moved toward much longer or effectively unlimited undo histories by storing deltas (the differences between states) rather than full snapshots, and by offloading history to the cloud. But even these systems have soft limits or caps on how far back you can go in a session. The 20-step default in desktop applications persists partly out of convention, partly out of genuine performance caution, and partly because most users — when studied — rarely undo more than five or six steps in a single session anyway.
Common Myths About Undo Limits (and What the History Actually Tells Us)
One widespread misconception is that a 20-step undo limit is a universal standard baked into operating systems. It isn't. Windows and macOS don't dictate undo depth — each application sets its own. Photoshop lets you configure history states up to 1,000 (though doing so will noticeably increase RAM usage). Microsoft Word's undo stack is effectively very deep for text edits. The "20 steps" you encounter is a per-application default, not a system-wide rule.
Another myth is that closing and reopening a file should preserve your undo history. In most applications, it doesn't, because the undo stack lives in working memory and is discarded when you close the session. Some newer collaborative tools do persist history across sessions, but this is still the exception rather than the rule. If you've ever wondered why you can't undo a change you made yesterday, this is why — the stack was cleared the moment you hit Save and closed the file.
People also sometimes assume that a longer undo history means a better application. In reality, it's a trade-off that depends heavily on what the software does. A pixel-by-pixel image editor has very different memory demands than a plain-text editor. Just as the answer to a question like why Cc still exists in work email turns out to be rooted in practical legacy rather than stubbornness, the undo limit is a practical inheritance — a decision that made perfect sense when it was made and has never had a compelling enough reason to be universally overturned.
The undo button is, in a sense, a small monument to humility in software design: an acknowledgment that users make mistakes and deserve a way back. Its limits remind us that even the most forgiving tools have to draw a line somewhere — and that the line was drawn thoughtfully, even if it doesn't always feel that way in the middle of a crisis.
This article explores the history and purpose behind everyday things and is for educational purposes only.