We get asked to add autosave to existing forms more often than almost any other single feature request, usually after a client has already lost a customer complaint or two about lost form progress. The frustrating part is that autosave has a reputation for being complicated to build well, when in reality most of the complexity comes from a handful of specific edge cases that are entirely predictable once you know to look for them.
Autosave sounds simple until you build it: save on every keystroke and you'll flood your backend with requests and probably introduce race conditions where an older save overwrites a newer one. Save too infrequently and you're back to the exact problem autosave was supposed to solve, users losing work. Here's a practical approach that avoids both failure modes.
Step 1: Debounce, Don't Save on Every Keystroke
Debouncing delays a save until the user has paused typing for a set interval, typically 500ms to 1500ms, rather than firing a request on every character. This alone eliminates the vast majority of unnecessary network calls. A user typing a paragraph into a textarea generates dozens of keystrokes but, with debouncing, only one or two save requests once they pause.
Step 2: Save on Field Blur, Not Just on a Timer
In addition to debounced saves during typing, trigger a save whenever a field loses focus, the user tabs or clicks to the next field. This catches the case where someone fills a field and immediately moves on before the debounce timer would have fired, which is common and would otherwise leave that field's changes unsaved for longer than necessary.
Step 3: Handle Out-of-Order Responses
If a user types quickly across multiple fields, save requests can complete out of order, an earlier request finishing after a later one due to network variance. Tag each save request with a monotonically increasing sequence number or timestamp, and on the client, discard any response that's older than the last one you've already applied. Without this, a slow early request can silently overwrite a user's more recent input.
Step 4: Distinguish Local Draft State From Server-Confirmed State
Save to local storage immediately and synchronously, on every change, since that's essentially free and gives you an instant safety net even if the network request fails entirely. Treat the backend save as a separate, asynchronous layer on top of that. This two-tier approach means a user who loses connectivity mid-form doesn't lose anything, local storage has them covered until the connection returns and the backend sync catches up.
Step 5: Show Save State Honestly
A small, unobtrusive "Saved" or "Saving..." indicator does more for user trust than almost any other UI element in an autosave flow. If a save fails, say so, "Couldn't save, retrying" rather than silently failing and leaving the user to assume everything is fine. Silent failures are how autosave systems lose the exact trust they're supposed to build.
Step 6: Set a Reasonable Retry and Backoff Strategy
Network requests fail. A save request that fails once shouldn't just vanish, retry with exponential backoff (wait 1 second, then 2, then 4, capping at a reasonable maximum) rather than hammering the server repeatedly or giving up after one attempt. If retries are exhausted, that's the moment to surface a visible warning to the user rather than failing silently in the background.
Local Storage Has Limits Worth Knowing
Browser local storage isn't infinite, and it's synchronous, which means large amounts of data written frequently can briefly block the main thread. The MDN Web Storage API reference covers the practical size limits (typically 5 to 10MB per origin depending on browser) and the tradeoffs against IndexedDB for larger or more frequent writes. For most form autosave use cases local storage is more than sufficient, but it's worth knowing where the ceiling is before you hit it in production.
What Happens When the Draft and the Final Submission Diverge
One detail teams often skip: what happens to the draft record once the form is finally submitted successfully. If the draft and the final submission live in separate tables or separate states, make sure the draft is explicitly cleared or marked complete on successful submission, otherwise you end up with orphaned draft records accumulating indefinitely, and worse, a confusing situation where a user who submits successfully but then somehow returns to the form sees stale draft data reappear instead of a fresh start.
Backend Considerations Worth Planning For
On the server side, autosave endpoints see far more traffic than a typical form submission endpoint, since they're hit repeatedly throughout a session rather than once at the end. Rate limiting per user session, and storing drafts in a lightweight, fast-write data store rather than the same heavily-indexed table used for finalized records, both help keep autosave from becoming a performance bottleneck as usage scales. The web.dev guidance on network resilience patterns covers debouncing and retry strategies in more general terms if you want a deeper reference beyond forms specifically.
Where Autosave Matters Most
Autosave has the highest payoff in exactly the scenario covered in our piece on multi-step form wizards that don't lose users halfway through: long, multi-step flows where a user might reasonably need to pause and return later. A single-field contact form barely benefits from autosave. A five-step application or onboarding flow benefits enormously, because the cost of losing progress scales directly with how much time a user has already invested.
What Happens When Two Tabs Are Open at Once
A user opening the same form in two browser tabs, deliberately or by accident, creates a genuine edge case that most autosave implementations never account for until it causes a support ticket. Without any coordination, both tabs will happily save over each other, with whichever tab saves last silently winning, potentially discarding real user input from the other tab.
A practical mitigation: use the browser's BroadcastChannel API or a shared local storage event listener to detect when a second tab opens the same form, and either warn the user directly ("This form is also open in another tab") or, for simpler cases, just make sure the local storage draft state is shared across tabs so both stay in sync automatically rather than diverging.
Choosing an Appropriate Debounce Interval Per Field Type
Not every field benefits from the same debounce timing. A short text field like a name might reasonably debounce at 500ms, since users type it quickly and pause naturally. A long textarea, like a cover letter or project description, benefits from a longer debounce, closer to 1500 or 2000ms, since users pause mid-thought constantly while composing longer text, and saving on every pause would generate far more requests than necessary. Tuning debounce intervals per field type, rather than using one blanket value across the whole form, meaningfully reduces unnecessary backend load on forms with a mix of short and long fields.
Testing It Properly Before Launch
Before shipping autosave, deliberately test the edge cases: what happens on a flaky connection, what happens if a user opens the same form in two tabs, what happens if local storage is full or disabled. These aren't hypothetical, they happen in production at meaningful volume, and an autosave system that only works under ideal network conditions isn't really solving the problem it was built for.
If you're planning a complex form or wizard flow and want help architecting the autosave and state persistence layer correctly the first time, 137Foundry builds exactly this kind of infrastructure as part of our web development work. More on our approach at 137foundry.com/services.
Top comments (0)