Recover a Failed File Upload Without Clearing the Form

A customer has described a service request, chosen a service and attached a photo. The upload fails, and the page clears the entire form. The attachment was the problem; rewriting the request is an extra failure the product could have avoided.

Define recovery at the attachment boundary before approving a form. The aim is to preserve the information your application is allowed to retain, explain what happened to the file and offer a next action that does not accidentally submit the request twice. The example below is a proposed test, not a reported client result.

AI-generated conceptual illustration; not a client screenshot.

Separate the form draft from the attachment state

Write down what each state means. A selected file is available to the current page; an uploaded file has reached the server; an accepted attachment has passed the application's required checks. A submitted request is a separate business outcome. Do not label all four states “Done.”

For a hypothetical maintenance request, agree that the description and chosen service remain editable after an upload error. Decide separately whether those fields may survive a refresh or only remain in the current page. Retention after sign-out, shared-device use and sensitive information need explicit rules; saving everything in browser storage is not a default recovery plan.

Show the attachment's current state beside its name. If the page has only remembered a filename, it must not present that label as proof that the server holds an accepted file.

Respect what the browser can restore

MDN's file-input documentation explains that a script cannot populate the picker by assigning a local filename to its value. It also notes that the accept attribute is a selection hint, not validation; the server must validate the upload.

If the page still has the file, a retry may reuse it. Otherwise, ask for reselection while retaining permitted text. Promise restoration after refresh only when the storage design supports it.

Give different failures different next actions

• Rejected file: identify the relevant type or size rule and let the person choose a replacement.
• Interrupted transfer: retain the permitted draft and offer a bounded retry when appropriate.
• Uncertain result: check the upload's server reference before creating another attachment.
• Cancelled selection or transfer: explain whether an earlier accepted attachment remains attached.

W3C WAI's form-notification guidance recommends clear feedback about success and errors, with understandable instructions for resolving problems. Apply that principle to the file control as well as the overall request.

For example: “The photo could not be uploaded. Your description is still here. Choose Retry or remove the photo.” Use that message only if the draft really remains available and both actions work. If the attachment is required, explain why final submission is unavailable. If it is optional, make submitting without it an explicit choice.

Run a focused recovery exercise

Use a test account, a harmless sample file and a clearly marked draft. Record the application version and browser. Fill every relevant field so that an unexpected reset becomes visible.

1. Reject a sample through an agreed validation rule. Replace only the attachment and check that the other fields retain their values.
2. Interrupt a transfer in the test environment. Restore connectivity, retry and verify one accepted attachment on the same draft.
3. Simulate a lost response after the server receives the file. Confirm the existing result before approving another upload.
4. Cancel a replacement and confirm whether the previous attachment remains, according to the agreed rule.
5. Refresh the page and check the documented retention behavior. If reselection is required, verify the instruction and the remaining draft fields.

Also complete the recovery using the keyboard and inspect the feedback with the supported assistive technology. A visible error alone does not establish that every user can find the next action.

Approve the saved result, not just the progress indicator

After recovery, submit the test request once and reopen it. Compare the description, service choice and attachment against the intended values. Verify that removing or replacing a file does not leave an unwanted attachment linked to the request.

Keep the acceptance record small: failure condition, fields retained, attachment state, next action and final request reference. Treat temporary-file cleanup and access permissions as additional implementation requirements. Passing this recovery exercise does not certify the security of an upload system.

Contact Dynelink to define file-upload recovery and acceptance checks for a business form or customer portal.