Validation that clears user input vs Inline validation vs Error summary vs Single-page form vs Autosave recovery vs Error state

Choose the validation-clears-input anti-pattern when client validation, server validation, failed submit, formatter rejection, retry, reload, or reauthentication erases safe user-entered values.

Validation that clears user input live example Inline validation live example Error summary live example Single-page form live example Autosave recovery live example Error state live example

Decision dimensions

Dimension	Validation that clears user input	Inline validation	Error summary	Single-page form	Autosave recovery	Error state
UI or UX	UI + UX - Anti-pattern where validation or failed submission destroys recoverable user-entered values	UI + UX - Field-level validation feedback	UI + UX - Form recovery summary	UI + UX - Short related multi-field submission page	UI + UX - Recovery surface for failed or uncertain background saves	UI + UX - Recoverable failure surface
UI guidance	Do not clear, replace, mask into emptiness, or reset user-entered values just because validation failed, the server rejected the payload, or a retry is needed.	Render a labeled field with hint text, field-adjacent error text, invalid styling, preserved value, and corrected state.	Render a top-of-form summary block with heading, linked error list, and matching field-level error messages.	Render a clear form heading, short instruction, required or optional indicator explanation, grouped related fields, one primary submit action, and a visible error summary only after failed submit.	Show a persistent recovery surface when autosave did not protect the latest work, naming the affected field or section, last server-saved time, local copy status, and available recovery actions.	Render a persistent error region near the affected content with a specific failure heading, plain-language cause, preserved context, and recovery actions.
UX guidance	Users should be able to fix the smallest wrong part of their answer without retyping unrelated work.	Help users correct a specific field without losing or re-entering the value they already typed.	Help users recover from one or more submitted-form errors without scanning the entire page.	Use a single-page form when users benefit from seeing, comparing, and editing a small related set of fields before one submission.	Use autosave recovery when users need to preserve effort after background saving fails, stalls, conflicts, expires, or only stores a local copy.	Help users recover when expected loading, saving, validation, sync, permission, or computation fails without losing their work.
Good UI	A failed email validation keeps maya@@example visible, shows Enter an email address in the correct format, and leaves the phone and message fields intact.	Error text appears next to the field with readable spacing, persistent label, hint text, and the invalid value still visible.	Top-of-form summary with a clear heading, linked error list, and matching inline field messages.	A contact-details form shows one heading, a required-field note, grouped name and contact fields, communication preference radios, aligned field errors, and a Save details button at the end.	A claim form says Household income answer failed to autosave at 10:42, keeps the typed answer visible, and offers Retry save, Copy answer, Restore last saved, and Continue after saved.	Reports could not load appears in the report section with the saved filter, Retry, Use cached data, and Contact support actions.
Bad UI	A checkout form fails cardholder-name validation and reloads with every shipping field blank.	Only a red border with no message.	Red banner saying fix errors with no links.	A long application with eligibility, address history, uploads, and payment fields is dumped onto one scrolling page.	A small toast says Could not save and disappears while the form still shows a green Saved label.	Tiny transient toast for a blocking failure.
Good UX	A user corrects one mistyped character in a preserved phone number after validation instead of re-entering the full number.	Validation appears after blur or submit when it helps correction.	After failed submit, focus or reading order makes the summary discoverable before users scan the form.	A user edits email and phone together, submits, sees two linked errors, fixes both without losing the preference selection, and saves the whole form once.	A user loses network while writing a long answer, sees it is saved on this device only, reconnects, retries the same value, and continues after the timestamp updates.	User input and filter context are preserved after failure, and retry returns to recovered content or a clear still-failed state.
Bad UX	A user uploads evidence, enters long notes, hits Submit, and loses the notes because one date was invalid.	Showing errors before users type.	Only showing errors below the fold.	A user submits a mixed form, sees a generic red banner, scrolls through many unrelated fields, and cannot find which answers failed.	A user submits after seeing Saved, but the newest section was failed and never reached the server.	Clearing work after save failure.
Best fit	Use this anti-pattern entry to audit forms, editors, imports, checkouts, onboarding flows, and configuration screens where validation can erase recoverable user work.	A single field has a specific correctable problem.	Form submission can produce one or more errors.	A compact set of related fields should be reviewed together before one submit.	Autosave failed, stalled, expired, or became uncertain while users still have meaningful local work.	A system or task failure blocks expected content or action.
Avoid when	Do not use this entry to prevent deliberately clearing sensitive secrets such as CVV, one-time codes, or passwords when policy requires it.	The main recovery task is finding several errors across a submitted page.	A single local field issue can be corrected before submit without page-level orientation.	The form is long, high-stakes, branched, or too hard to recover from on one page.	The product does not use autosave or local draft persistence.	Nothing exists yet and the state is expected.
Required state	Initial typed state with values entered across multiple fields.	Neutral field with label, hint, and no error.	Neutral form before submit with no summary.	Initial empty state with form heading, instruction, required or optional indicator explanation, grouped fields, and submit action.	Clean saved state with current server timestamp.	Normal expected state before failure.
Accessibility burden	Preserved values must remain in their controls so screen reader and keyboard users can edit them in place.	Expose invalid state on the input and connect error text to the field description where possible.	Use a heading and alert behavior that makes the summary discoverable.	Keep field order in the DOM the same as the visible order.	Announce failed, local-only, retrying, recovered, and conflict states through status text without repeating every save attempt.	Use appropriate alert or status semantics for newly appearing critical errors.
Common misuse	Calling form reset after submit regardless of success or failure.	Showing field errors before users have interacted with the control.	Showing a red banner or toast with no links to the invalid answers.	Using one page for a long complex application just to avoid designing steps.	Leaving a green Saved label visible after a failed or stale autosave.	Using a transient toast for critical errors.

Validation that clears user input

UI or UX: UI + UX - Anti-pattern where validation or failed submission destroys recoverable user-entered values
UI guidance: Do not clear, replace, mask into emptiness, or reset user-entered values just because validation failed, the server rejected the payload, or a retry is needed.
UX guidance: Users should be able to fix the smallest wrong part of their answer without retyping unrelated work.
Good UI: A failed email validation keeps maya@@example visible, shows Enter an email address in the correct format, and leaves the phone and message fields intact.
Bad UI: A checkout form fails cardholder-name validation and reloads with every shipping field blank.
Good UX: A user corrects one mistyped character in a preserved phone number after validation instead of re-entering the full number.
Bad UX: A user uploads evidence, enters long notes, hits Submit, and loses the notes because one date was invalid.
Best fit: Use this anti-pattern entry to audit forms, editors, imports, checkouts, onboarding flows, and configuration screens where validation can erase recoverable user work.
Avoid when: Do not use this entry to prevent deliberately clearing sensitive secrets such as CVV, one-time codes, or passwords when policy requires it.
Required state: Initial typed state with values entered across multiple fields.
Accessibility burden: Preserved values must remain in their controls so screen reader and keyboard users can edit them in place.
Common misuse: Calling form reset after submit regardless of success or failure.

Inline validation

UI or UX: UI + UX - Field-level validation feedback
UI guidance: Render a labeled field with hint text, field-adjacent error text, invalid styling, preserved value, and corrected state.
UX guidance: Help users correct a specific field without losing or re-entering the value they already typed.
Good UI: Error text appears next to the field with readable spacing, persistent label, hint text, and the invalid value still visible.
Bad UI: Only a red border with no message.
Good UX: Validation appears after blur or submit when it helps correction.
Bad UX: Showing errors before users type.
Best fit: A single field has a specific correctable problem.
Avoid when: The main recovery task is finding several errors across a submitted page.
Required state: Neutral field with label, hint, and no error.
Accessibility burden: Expose invalid state on the input and connect error text to the field description where possible.
Common misuse: Showing field errors before users have interacted with the control.

Error summary

UI or UX: UI + UX - Form recovery summary
UI guidance: Render a top-of-form summary block with heading, linked error list, and matching field-level error messages.
UX guidance: Help users recover from one or more submitted-form errors without scanning the entire page.
Good UI: Top-of-form summary with a clear heading, linked error list, and matching inline field messages.
Bad UI: Red banner saying fix errors with no links.
Good UX: After failed submit, focus or reading order makes the summary discoverable before users scan the form.
Bad UX: Only showing errors below the fold.
Best fit: Form submission can produce one or more errors.
Avoid when: A single local field issue can be corrected before submit without page-level orientation.
Required state: Neutral form before submit with no summary.
Accessibility burden: Use a heading and alert behavior that makes the summary discoverable.
Common misuse: Showing a red banner or toast with no links to the invalid answers.

Single-page form

UI or UX: UI + UX - Short related multi-field submission page
UI guidance: Render a clear form heading, short instruction, required or optional indicator explanation, grouped related fields, one primary submit action, and a visible error summary only after failed submit.
UX guidance: Use a single-page form when users benefit from seeing, comparing, and editing a small related set of fields before one submission.
Good UI: A contact-details form shows one heading, a required-field note, grouped name and contact fields, communication preference radios, aligned field errors, and a Save details button at the end.
Bad UI: A long application with eligibility, address history, uploads, and payment fields is dumped onto one scrolling page.
Good UX: A user edits email and phone together, submits, sees two linked errors, fixes both without losing the preference selection, and saves the whole form once.
Bad UX: A user submits a mixed form, sees a generic red banner, scrolls through many unrelated fields, and cannot find which answers failed.
Best fit: A compact set of related fields should be reviewed together before one submit.
Avoid when: The form is long, high-stakes, branched, or too hard to recover from on one page.
Required state: Initial empty state with form heading, instruction, required or optional indicator explanation, grouped fields, and submit action.
Accessibility burden: Keep field order in the DOM the same as the visible order.
Common misuse: Using one page for a long complex application just to avoid designing steps.

Autosave recovery

UI or UX: UI + UX - Recovery surface for failed or uncertain background saves
UI guidance: Show a persistent recovery surface when autosave did not protect the latest work, naming the affected field or section, last server-saved time, local copy status, and available recovery actions.
UX guidance: Use autosave recovery when users need to preserve effort after background saving fails, stalls, conflicts, expires, or only stores a local copy.
Good UI: A claim form says Household income answer failed to autosave at 10:42, keeps the typed answer visible, and offers Retry save, Copy answer, Restore last saved, and Continue after saved.
Bad UI: A small toast says Could not save and disappears while the form still shows a green Saved label.
Good UX: A user loses network while writing a long answer, sees it is saved on this device only, reconnects, retries the same value, and continues after the timestamp updates.
Bad UX: A user submits after seeing Saved, but the newest section was failed and never reached the server.
Best fit: Autosave failed, stalled, expired, or became uncertain while users still have meaningful local work.
Avoid when: The product does not use autosave or local draft persistence.
Required state: Clean saved state with current server timestamp.
Accessibility burden: Announce failed, local-only, retrying, recovered, and conflict states through status text without repeating every save attempt.
Common misuse: Leaving a green Saved label visible after a failed or stale autosave.

Error state

UI or UX: UI + UX - Recoverable failure surface
UI guidance: Render a persistent error region near the affected content with a specific failure heading, plain-language cause, preserved context, and recovery actions.
UX guidance: Help users recover when expected loading, saving, validation, sync, permission, or computation fails without losing their work.
Good UI: Reports could not load appears in the report section with the saved filter, Retry, Use cached data, and Contact support actions.
Bad UI: Tiny transient toast for a blocking failure.
Good UX: User input and filter context are preserved after failure, and retry returns to recovered content or a clear still-failed state.
Bad UX: Clearing work after save failure.
Best fit: A system or task failure blocks expected content or action.
Avoid when: Nothing exists yet and the state is expected.
Required state: Normal expected state before failure.
Accessibility burden: Use appropriate alert or status semantics for newly appearing critical errors.
Common misuse: Using a transient toast for critical errors.

Decision rules

Choose the validation-clears-input anti-pattern when client validation, server validation, failed submit, formatter rejection, retry, reload, or reauthentication erases safe user-entered values.
Choose the validation-clears-input anti-pattern when a failed field clears valid sibling fields, long text, uploaded file names, selected options, pasted raw values, or local draft state.
Choose inline validation when one field has a correctable problem and the typed value remains visible and editable beside the field message.
Choose error summary when users need a linked overview after submit; the summary should route to preserved field values, not blank rebuilt controls.
Choose single-page form when several related values are submitted together and validation must preserve all safe values across the page.
Choose autosave recovery when background save failure or ambiguity means the newest local value needs retry, copy, restore, or compare controls before it can be trusted.
Choose error state when a system, network, save, sync, or load failure blocks progress and users need persistent recovery while their context is preserved.
Use password-input or payment-field security rules only for narrow sensitive values; do not generalize those rules to ordinary text, address, date, phone, textarea, or selection fields.
Do not silently normalize by deleting user input; preserve raw input, show the interpreted value, or ask for correction.
Reset, Clear form, Cancel, Discard, and Start over are deliberate actions and must not be triggered as a side effect of validation.
After server validation, rehydrate submitted values before focusing the error summary or first invalid field; do not rebuild the page from blank defaults.
If policy clears a sensitive value, keep non-sensitive values intact and explain which field was cleared and why.

Inspect live examples

Validation that clears user input Inline validation Error summary Single-page form Autosave recovery Error state

Failure modes

A failed email check clears the email field, so the user cannot correct one mistyped character.
A server-side address validation response rebuilds the form from blank defaults.
A formatter rejects a pasted phone number and deletes the raw pasted value.
A textarea length error removes the entire long answer.
One invalid uploaded file clears every selected valid file.
Session expiry returns users to a blank form after reauthentication.
A retry action sends empty values because the failed local payload was discarded.
Password-clearing behavior is applied to non-secret profile, checkout, or application fields.