Validation that clears user input

Problem Context

• A form, editor, checkout, upload, import, authentication, or configuration screen validates user-entered values on blur, submit, save, retry, or server response.
• Validation can fail locally, through server-side rules, from normalization or masking, after session expiry, during autosave, or after a network error.
• The user may have entered multiple related fields, long text, uploads, selected options, pasted values, or formatted values that are expensive to recreate.
• Some sensitive values such as passwords, card verification codes, or one-time codes may need special clearing rules, but that exception must not be generalized to ordinary fields.

Selection Rules

• Flag this anti-pattern when validation failure, failed submit, server rejection, formatting, retry, reload, or route return clears safe user-entered values.
• Use inline validation when one field can be corrected locally while its failing value remains visible and editable.
• Use error summary when failed submit produces one or more errors and users need linked recovery without losing values.
• Use single-page form when several related fields are submitted together and all entered values must survive validation.
• Use autosave recovery when a background save failed or became uncertain and the latest local value needs explicit recovery.
• Use error state when a save/load/sync failure blocks progress but the primary task is system failure recovery rather than field correction.
• Preserve invalid values unless they are unsafe to redisplay, impossible to store, or policy requires clearing a specific sensitive secret.
• If a value must be cleared for security, say which value was cleared, why, and how to re-enter only that value.
• Do not normalize by deleting user input silently; show the interpreted value, preserve the raw value when useful, or ask for confirmation.
• Do not clear valid sibling fields, hidden active fields, file selections, filters, or long text because a different field failed validation.

Required States

• Initial typed state with values entered across multiple fields.
• Field-level invalid state with the failing value preserved and editable.
• Submit failed state with error summary, matching field messages, and all safe values preserved.
• Server validation returned state with the submitted payload safely rehydrated into the form.
• Network or retry state where the same local value remains visible until retry succeeds or is explicitly discarded.
• Formatter or mask rejected state where raw input is preserved with correction guidance.
• Long text over-limit state where the draft remains and excess is identified rather than removed.
• File or upload validation state where acceptable uploaded files and filenames remain while failed files are explained.
• Session expired return state where safe local values are restored after reauthentication.
• Sensitive exception state where a password, CVV, or one-time code is cleared with explicit reason while non-sensitive fields remain.
• Bad full-reset state where all fields are blank after one validation error.
• Bad field-wipe state where the invalid field is emptied and users must retype from memory.
• Bad sibling-loss state where unrelated valid fields are cleared.
• Bad formatter-loss state where formatting destroys the raw value.
• Bad upload-loss state where every selected file disappears after one file fails.

Interaction Contract

• Validation messages name the problem and leave the user's value in place for editing.
• Submit-time recovery keeps all safe field values, selected options, file names, expanded sections, and scroll context available.
• Server validation responses rehydrate the submitted values before moving focus to the error summary or first invalid field.
• Retry sends the latest preserved local value, not a blank default or stale server value.
• Formatters and masks do not erase raw input; they either preserve it, show the interpreted value, or ask for correction.
• Security-sensitive clearing is scoped to the sensitive field and explained without clearing unrelated values.
• Reset, Clear, Cancel, and Start over are separate deliberate actions and are not triggered by validation.

Implementation Checklist

• Keep form state separate from validation state so adding an error cannot reset field values.
• On failed submit, render the previous submitted values back into every safe control before showing errors.
• Return server validation errors with field keys and the submitted values or preserve the client-side payload until response handling completes.
• Preserve raw and formatted values separately for masks, currency, dates, phone numbers, addresses, and IDs.
• Protect long text and uploads with local draft or temporary object state while validation runs.
• Handle network failure, retry, session expiry, route reload, browser Back, and reauthentication without falling back to blank defaults.
• Define explicit exceptions for passwords, card verification codes, one-time codes, and prohibited file contents; clear only those values and explain the reason.
• Test failed client validation, failed server validation, slow network, reload, reauth, mobile keyboard, pasted input, autofill, uploads, long textarea text, and screen reader recovery.

Common Generated-UI Mistakes

• Calling form reset after submit regardless of success or failure.
• Replacing the user's raw value with an empty string when parsing fails.
• Re-rendering the form from default values after a server validation response.
• Clearing every field because one field was invalid.
• Clearing uploaded files without preserving valid file names or explaining the failed file.
• Using password-clearing rules as an excuse to clear ordinary text fields.
• Showing only a toast after data loss instead of restoring the user's work.
• Combining Reset and Submit controls so users accidentally erase work while fixing validation.

Critique Questions

• Which values survive client validation, server validation, retry, reload, and session return?
• Can the user edit the failing value directly, or must they retype it?
• Are valid sibling fields preserved when one field fails?
• Does formatting preserve raw input or explain how it was interpreted?
• What sensitive fields are deliberately cleared, and is the reason visible?
• Can long text, uploads, and selected options be recovered after an error?
• Does the error summary link to fields without rebuilding the form from defaults?