If attachments are required in a form that can be saved as a draft, should the user be able to delete it or replace only?

  • 59
    Anecdotally, I have received many, many help desk calls from confused users who accidentally uploaded the wrong document into a form, then struggled to delete it (because we only allow replacement, not deletion). If you're going to enforce a replacement-only rule, please make it very clear to the user that that's the rule.
    – Joel H.
    Commented Oct 23, 2017 at 15:36
  • 9
    I think you should be able to delete all attachments. But you could add that if they delete all the attachments, then the form cannot be taken out of draft until an attachment is done.l Commented Oct 24, 2017 at 15:00
  • 3
    Consider that a user should be free to begin completing a form in one session, and finish the work and submit it in a different session, perhaps even on a different device. They could start, realize that the file they need is on some other device, then complete the work there. Don't box people in to a flow that the Web does not require, let them do what it allows. All actions should be as stand-alone as possible.
    – user67695
    Commented Oct 26, 2017 at 14:02
  • 2
    Why not? Maybe you uploaded the wrong and do not have the right one available to replace it. There is no advantage in forcing the user to keep wrong content. Commented Oct 27, 2017 at 10:54
  • If you were a user what would you want to happen if you accidently uploaded a scanned copy of your passport? Commented Oct 27, 2017 at 19:28

6 Answers 6


Let the user do what they want, then enforce your requirements at form submission.

Preventing deletion is no help to the user whatsoever. This does not help them successfully complete the form, but instead prevents them from fixing their mistakes. There's no need to prevent deletion when the user isn't even trying to submit the form yet.

  • 57
    As a trivial analogy showing how stupid "preventing deletion" is, imagine if all mandatory text-entry fields refused to let you backspace the last character once you'd typed at least one character into them, rather than just blocking final submission as long as they're empty. Commented Oct 24, 2017 at 19:23
  • 7
    @R.. On the other hand though, radio buttons only very rarely offer any way to delete your input without replacing it with something else. Commented Oct 24, 2017 at 21:02
  • 17
    @AJMansfield: Uhg. I've always thought sets of radio buttons that started with none selected and could not be returned to their initial state were broken ux, but I'd never considered it in this context. Yeah they're wrong too. Commented Oct 24, 2017 at 23:15
  • 3
    @AJMansfield Most radio buttons I've encountered recently had "not applicable" option I could easily click. Not the same, but pretty good replacement, and sign that form designer actually cared.
    – Mołot
    Commented Oct 25, 2017 at 11:17
  • 6
    Unlike the other examples, radio buttons have limited, predefined choices. Assuming a selection is required, I don't think you would need to clear the selection, just change it. Text entries and (especially) file uploads allow any input and are another matter.
    – ArrowCase
    Commented Oct 25, 2017 at 20:14

It depends on what happens to the uploaded file, and on the user and the context, but I would generally say that they should be able to delete.

Without the capability to delete, it's possible for a user to accidentally upload an incorrect file... and they are then forced to leave that incorrect file in place (knowing an error has been made) until they can locate the correct file and re-upload.

For the entire time it takes from the discovery of the error to the successful upload of the correct version, the wrong version is still present. Depending on the context, this could range from being mildly inconvenient to being a catastrophic error... both of which could be avoided (or at least minimized) with a delete option.

  • 3
    @AntonChanning Huh? SE won't let you edit your comment after five minutes, by you can always delete. Commented Oct 26, 2017 at 9:40
  • 1
    Sorry must have been tired. Couldn't see the delete button... :D
    – ToniWidmo
    Commented Oct 26, 2017 at 10:21

Your question has 2 options

  1. If there is only single attachment then the user needs to replace it.

  2. The user will attach more than one attachments then you need to give a delete option because if the user attached 5 items at a time by mistake and he/she wants to remove 2 attachments then you need to give delete option.

  • 62
    Option 1 is horrible. What if I upload the wrong file, etc. Total nightmare. Put the user in control, especially of her own data. Jesus.
    – vidstige
    Commented Oct 23, 2017 at 17:32
  • 19
    I hate the idea of not being able to delete if I uploaded the wrong file. It would stress me out thinking that I'm an accidental click away from submitting something incorrectly--whereas if I can delete the file, there's no way something incorrect will accidentally get submitted.
    – spacetyper
    Commented Oct 23, 2017 at 19:32
  • 27
    Allow deletion without replacement. If someone's uploaded the wrong file, especially if it's sensitive, they will want to delete it without having to find the right file first.
    – TripeHound
    Commented Oct 23, 2017 at 20:09
  • 13
    @foch Why option 1 doesn't work: Let's say user Bob accidentally uploads a document with private information. (Social security number, credit card details, pornographic content). Bob would want to delete this content as soon as possible, without needing to find a replacement document first.
    – Stevoisiak
    Commented Oct 24, 2017 at 16:07
  • 5
    @foch Saving 1 click is not important if it causes the user to wonder what it does/if it did what they wanted/if the other document has been actually deleted. Commented Oct 24, 2017 at 19:52

There could be a legal issue here:

What if the user accidentally uploaded a document they have no right to upload?

Unless the upload is somehow like a signed contract, where you need to keep it to prove you got the signature, and you've already confirmed the signatures and entered into a contract, let them delete it.

If that leaves the job incomplete, mark the form as "incomplete" and wait with actually processing it until the missing file has been added.


To add another reason: having no file present clearly let's the user know that portion of the form is incomplete.

Consider if a user started filling in the form and uploaded the wrong file (or a file that later turns out to be wrong, etc.). The correct file isn't available—say it hasn't been produced yet. The user then notices, and can't delete it — only replace. So the incorrect file stays. And the user is forced to remember this detail—you've prevented the knowledge from being stored by the form state.

What happens if the user has to do something else, and comes back to it in a week or two? Will the user remember that the apparently-completed document section is actually the wrong document? Quite possibly not, leading to the form being submitted with the wrong document.


I think it would be better to handle the delete option with an Archive. There may be also legal side regarding deleting the documents. For eg: Signed documents should never be deleted. So, it's more a contextually driven decision based on your client. Anyway, it would be good to have a confirmation stage before deleting.

  • 4
    I'm not sure how this answers the question. In particular, the question is about form submission, so "delete" doesn't mean "destroy the file", it just means "don't include it with the form." Commented Oct 26, 2017 at 9:43
  • "Archive" would typically make sense for versions of submitted content. The user has the expectation that, until they click "submit", they aren't actually sending you anything, and so any changes will not be recorded.
    – user31143
    Commented Oct 27, 2017 at 12:33
  • @DavidRicherby Actually, the question talks about the form being saved as draft, suggesting the file might well have been sent to the server. However, from the user's point of view, it would probably make sense to treat it as though it hasn't yet been "sent", so I agree that no archiving would be necessary.
    – IMSoP
    Commented Oct 30, 2017 at 9:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.