Autosave
Last updated:
Practical patterns for background saving that users can see, trust, and recover when it fails.
01 — Foundation
Autosave should feel reliable
Background saving reduces anxiety only when users can see it working — and trust recovery when it fails.
Autosave drafts changes without an explicit submit. Invisible autosave creates paranoia; noisy autosave spams assistive technology. This pattern focuses on debouncing, visibility, conflicts, and failure — see also Save States for the full saved / saving / failed model.
02 — Feedback
Visible, calm status
“Saved” should mean something — include scope and timing.
- show saving, saved, and failed states near the content being edited
- prefer “All changes saved” or “Draft saved at 14:32” over a flickering icon
- debounce edits — do not POST on every keypress
- batch aria-live announcements — do not announce every autosave tick
<p role="status" aria-live="polite" id="autosave-status">
All changes saved.
</p>03 — Conflicts
Conflicts and navigation
Two tabs, two editors, one record — plan for collisions.
- detect version conflicts and show merge or refresh options
- warn before leaving when a save is in flight or failed
- queue saves offline when appropriate — see Offline States
04 — Scope
What to autosave
Not every field belongs on a background timer.
- good fits: long forms, editors, draft content, settings panels
- poor fits: payment submission, irreversible commits — use explicit confirm
- separate autosave from publish — users should know what is live vs draft
05 — Review
Before you approve
A short checklist for autosave in code review.
- status is visible; debouncing prevents server spam
- failures are specific with retry; conflicts are handled
- live regions are polite; draft vs published is clear