Exit warning vs Autosave form vs Draft state vs Confirmation dialog

Use exit warning when the user has started leaving the current surface and departure would lose unsaved work, unsent files, payment state, authentication context, or another unrecoverable in-progress task.

Exit warning live example Autosave form live example Draft state live example Confirmation dialog live example

Decision dimensions

Dimension	Exit warning	Autosave form	Draft state	Confirmation dialog
UI or UX	UI + UX - Attempted-departure safeguard for unrecoverable in-progress work	UI + UX - Background-saving form progress	UI + UX - Unpublished object version lifecycle	UI + UX - Consequential alert decision
UI guidance	Show a warning only when the user attempts to leave with real unsaved, pending, failed, or unrecoverable work; place in-app route warnings at the point of departure with Save and leave, Discard and leave, and Stay editing choices.	Render a clear autosave message before users start, then keep a persistent status surface for Pending, Saving, Saved with timestamp, Failed, Retry, and unsafe-to-leave states.	Label the current version explicitly as Draft, Unpublished changes, Published, Active, Locked, or Unavailable, and place that label near the object title, list row, editor header, and publish actions.	Render an alert-style modal decision with a specific title, consequence description, safe cancellation, and a destructive action label that names the object or scope.
UX guidance	Use exit warning to interrupt an attempted departure that would lose work, context, payment state, upload progress, or session-bound data the product cannot safely recover.	Use autosave when losing progress would hurt and background persistence is safer than making users hunt for a distant Save button.	Use draft state when users need to pause work on an object, return later, and decide whether to publish, activate, discard, or keep editing an unpublished version.	Interrupt users only when the action has a meaningful consequence that cannot be safely recovered afterward.
Good UI	A grant form user clicks Back with two unsaved answers; a dialog names the changed section and offers Save and leave, Discard and leave, or Stay editing.	A long application step says the application is saved on every change, shows Saving after an edited title blurs, then shows Draft saved just now with a timestamp.	A knowledge article header says Draft saved today, shows the currently published title, and offers Resume draft, Compare with published, Discard draft, and Publish.	Delete Research archive? explains that 14 notes and shared links will be permanently removed, offers Keep archive, and labels the danger action Delete archive.
Bad UI	Every navigation shows Are you sure you want to leave? even after the form is saved.	A form removes the Save button and shows no save status, leaving users unsure whether typed answers are safe.	An editor opens directly into draft text but the header only says Saved, so users cannot tell whether viewers see the changes.	A popup says Are you sure? with OK and Cancel but does not name the project, notes, or irreversible outcome.
Good UX	A user starts to close a tab after a failed autosave, sees the risk before leaving, stays on the page, retries the save, and then leaves without another warning.	A user writes a long answer, pauses, sees Saving, then sees Draft saved just now and can leave knowing the draft is recoverable.	A user opens a published article that has an unpublished version, chooses Resume draft, reviews a change summary, publishes, and sees the page become visible to viewers.	Cancel, Escape, and Keep archive leave the archive unchanged and return focus to Delete archive.
Bad UX	A user clicks a sidebar link after typing a long answer and loses it because the product only watched final Submit.	A user leaves after seeing an old saved message, but the newest field was never persisted.	A user closes an editor after seeing Saved, later discovers the page was never published, and cannot find the draft in the content list.	Every archive, filter, and dismiss action opens the same confirmation until users click through automatically.
Best fit	Users have unsaved or pending changes that cannot be recovered if they leave.	Users spend meaningful time entering form content or application progress.	Users create or edit objects that should not become visible, active, submitted, or externally effective until a later action.	The action is destructive, irreversible, costly, security-sensitive, privacy-affecting, or externally visible.
Avoid when	The page is clean, read-only, or all changes are safely saved and recoverable.	The form is short enough that a visible manual Save or Submit is clearer.	The change is a small one-field edit that should be saved or canceled immediately.	The action is routine and easily reversible.
Required state	Clean state with no exit warning attached.	Initial state that explains progress will be saved automatically.	Published or active state with no draft.	Pre-action state with an explicit consequential trigger.
Accessibility burden	Use a real dialog or alertdialog for in-app warnings, with a heading that names the loss risk.	Expose autosave status changes in a polite status region so assistive technology users hear Saving, Saved, and Failed states.	Expose Draft, Published, Unpublished changes, Locked, and Unavailable as text in the page title area and list rows, not only by color or icon.	Use alertdialog semantics or platform equivalent when the decision is urgent and requires a response.
Common misuse	Warning on every navigation regardless of whether work is dirty.	Removing the Save button while providing no autosave status.	Using Saved to mean both saved draft and published content.	Asking users to confirm every routine action until they stop reading.

Exit warning

UI or UX: UI + UX - Attempted-departure safeguard for unrecoverable in-progress work
UI guidance: Show a warning only when the user attempts to leave with real unsaved, pending, failed, or unrecoverable work; place in-app route warnings at the point of departure with Save and leave, Discard and leave, and Stay editing choices.
UX guidance: Use exit warning to interrupt an attempted departure that would lose work, context, payment state, upload progress, or session-bound data the product cannot safely recover.
Good UI: A grant form user clicks Back with two unsaved answers; a dialog names the changed section and offers Save and leave, Discard and leave, or Stay editing.
Bad UI: Every navigation shows Are you sure you want to leave? even after the form is saved.
Good UX: A user starts to close a tab after a failed autosave, sees the risk before leaving, stays on the page, retries the save, and then leaves without another warning.
Bad UX: A user clicks a sidebar link after typing a long answer and loses it because the product only watched final Submit.
Best fit: Users have unsaved or pending changes that cannot be recovered if they leave.
Avoid when: The page is clean, read-only, or all changes are safely saved and recoverable.
Required state: Clean state with no exit warning attached.
Accessibility burden: Use a real dialog or alertdialog for in-app warnings, with a heading that names the loss risk.
Common misuse: Warning on every navigation regardless of whether work is dirty.

Autosave form

UI or UX: UI + UX - Background-saving form progress
UI guidance: Render a clear autosave message before users start, then keep a persistent status surface for Pending, Saving, Saved with timestamp, Failed, Retry, and unsafe-to-leave states.
UX guidance: Use autosave when losing progress would hurt and background persistence is safer than making users hunt for a distant Save button.
Good UI: A long application step says the application is saved on every change, shows Saving after an edited title blurs, then shows Draft saved just now with a timestamp.
Bad UI: A form removes the Save button and shows no save status, leaving users unsure whether typed answers are safe.
Good UX: A user writes a long answer, pauses, sees Saving, then sees Draft saved just now and can leave knowing the draft is recoverable.
Bad UX: A user leaves after seeing an old saved message, but the newest field was never persisted.
Best fit: Users spend meaningful time entering form content or application progress.
Avoid when: The form is short enough that a visible manual Save or Submit is clearer.
Required state: Initial state that explains progress will be saved automatically.
Accessibility burden: Expose autosave status changes in a polite status region so assistive technology users hear Saving, Saved, and Failed states.
Common misuse: Removing the Save button while providing no autosave status.

Draft state

UI or UX: UI + UX - Unpublished object version lifecycle
UI guidance: Label the current version explicitly as Draft, Unpublished changes, Published, Active, Locked, or Unavailable, and place that label near the object title, list row, editor header, and publish actions.
UX guidance: Use draft state when users need to pause work on an object, return later, and decide whether to publish, activate, discard, or keep editing an unpublished version.
Good UI: A knowledge article header says Draft saved today, shows the currently published title, and offers Resume draft, Compare with published, Discard draft, and Publish.
Bad UI: An editor opens directly into draft text but the header only says Saved, so users cannot tell whether viewers see the changes.
Good UX: A user opens a published article that has an unpublished version, chooses Resume draft, reviews a change summary, publishes, and sees the page become visible to viewers.
Bad UX: A user closes an editor after seeing Saved, later discovers the page was never published, and cannot find the draft in the content list.
Best fit: Users create or edit objects that should not become visible, active, submitted, or externally effective until a later action.
Avoid when: The change is a small one-field edit that should be saved or canceled immediately.
Required state: Published or active state with no draft.
Accessibility burden: Expose Draft, Published, Unpublished changes, Locked, and Unavailable as text in the page title area and list rows, not only by color or icon.
Common misuse: Using Saved to mean both saved draft and published content.

Confirmation dialog

UI or UX: UI + UX - Consequential alert decision
UI guidance: Render an alert-style modal decision with a specific title, consequence description, safe cancellation, and a destructive action label that names the object or scope.
UX guidance: Interrupt users only when the action has a meaningful consequence that cannot be safely recovered afterward.
Good UI: Delete Research archive? explains that 14 notes and shared links will be permanently removed, offers Keep archive, and labels the danger action Delete archive.
Bad UI: A popup says Are you sure? with OK and Cancel but does not name the project, notes, or irreversible outcome.
Good UX: Cancel, Escape, and Keep archive leave the archive unchanged and return focus to Delete archive.
Bad UX: Every archive, filter, and dismiss action opens the same confirmation until users click through automatically.
Best fit: The action is destructive, irreversible, costly, security-sensitive, privacy-affecting, or externally visible.
Avoid when: The action is routine and easily reversible.
Required state: Pre-action state with an explicit consequential trigger.
Accessibility burden: Use alertdialog semantics or platform equivalent when the decision is urgent and requires a response.
Common misuse: Asking users to confirm every routine action until they stop reading.

Decision rules

Use exit warning when the user has started leaving the current surface and departure would lose unsaved work, unsent files, payment state, authentication context, or another unrecoverable in-progress task.
Use autosave form when the main solution is to persist progress automatically so navigation can usually happen without interruption.
Use draft state when the work exists as a durable unpublished object that users can resume, compare, discard, or publish from lists and deep links.
Use confirmation dialog when the user explicitly chose a risky action such as delete, submit, discard, or cancel; exit warning is for attempted route, tab, reload, back, or sign-out departure.
Exit warnings should be conditional on real unsaved or unsafe state and removed after save, submit, discard, or successful autosave.
Do not warn on every navigation for analytics, retention, or engagement; warnings must identify a user-facing loss or consequence.
For in-app route changes, show a custom decision surface that can name Save and leave, Discard and leave, and Stay editing; for browser close or reload, expect the browser-owned message and keep a local recovery path visible before the attempt.
If autosave is pending or failed, the exit warning must say whether Save and leave can complete, whether Retry is needed, or whether leaving discards the latest change.
If a draft is recoverable after leaving, do not overstate loss; route users to Resume draft or View saved draft instead of blocking departure.
A confirmation dialog that discards changes can be the UI used inside an exit warning flow, but the pattern boundary is still the attempted exit trigger and dirty-state logic.

Inspect live examples

Exit warning Autosave form Draft state Confirmation dialog

Failure modes

A form warns even when no fields changed, training users to ignore the warning.
A user clicks Back after a failed autosave and loses the latest answer without any interruption.
The warning says You have changes but does not name what will be lost or offer Save, Discard, and Stay choices.
The app traps users by disabling Leave even after they choose to discard changes.
The beforeunload listener remains after the draft is saved, harming navigation and browser cache behavior.
A browser-close warning uses custom in-app copy that cannot appear in the browser-owned dialog, leaving users with misleading expectations.