Should a form remember what someone typed if they navigate away?

Yes, a form should remember what someone typed by default, because losing a half-filled form is one of the most severe and trust-breaking failures an interface can inflict, and the only real exception is sensitive data that should not persist for security reasons. The default is to preserve, not to discard. When a user has invested ten minutes typing answers and then taps back, refreshes by accident, or gets pulled into another tab, finding their work erased is not a minor inconvenience, it is the kind of betrayal that makes people abandon a task and distrust the product. Retaining their input across accidental navigation and interruptions is the baseline expectation, and clearing it is the behavior that needs justifying.

The reasoning is asymmetry of cost. Preserving entered data costs the product almost nothing, while losing it costs the user everything they put in, and that imbalance should settle the question on its own. People do not fill forms in pristine, uninterrupted sessions. They get a phone call, switch tabs to look something up, fat-finger the back gesture, or have the browser reload under them. Every one of those everyday events becomes a catastrophe if the form treats navigation as a reason to throw away the user’s work. A form that forgets punishes the user for living a normal life around it, and because the failure feels like the product’s carelessness rather than their own mistake, the trust damage lands squarely on you.

Consider someone filling out a detailed support request, several paragraphs describing a problem, who clicks a link to grab their order number and then hits back to return to the form. If the fields are empty, they have lost paragraphs of carefully written context, and many will simply give up rather than retype it, taking their frustration with them. If the form remembered, they return to find every word intact, add the order number, and submit, never even noticing the round trip. Same user, same detour, opposite outcome, and the only variable was whether the form held onto what they had typed. The remembering version is invisible when it works, which is exactly why it is so easy to underbuild and so damaging to skip.

The catch is the security exception, where some data genuinely should not linger. A password, a full payment card number, a one-time code, or other sensitive credentials should not be retained across navigation, because persisting them anywhere they could be recovered creates a real risk that outweighs the convenience. So the rule is not “remember everything,” it is “remember by default, and deliberately exclude the fields where persistence would be a security liability.” That carve-out is narrow and specific. It applies to genuinely sensitive secrets, not to the long, tedious, non-sensitive fields that make up most of a form and that users most resent losing.

So treat input persistence as the default and data loss as the thing you have to justify. Build forms to retain what the user has entered across back navigation, refreshes, and interruptions, so an accidental detour never costs them their work, and test it deliberately by half-filling a form, leaving, and coming back to confirm the data survived. Then go through the fields and exclude only the genuinely sensitive ones, the passwords and payment secrets, from being remembered. Preserve by default, drop persistence only where security demands it, and you will spare your users the single most infuriating form failure there is.