Collecting files by email means a folder nobody can search, attachments stripped by mail filters, and three versions of the same document with different names. A form fixes that, and introduces a smaller set of problems worth knowing about in advance.
This covers the decisions: size, types, whether to require it, and what happens to the file afterwards.
What people actually upload
The common cases, and what each one needs.
- CVs and cover letters. PDF and Word, around 10 MB. Expect PDF from most people and do not reject .doc from the ones who still use it.
- Photographs of a problem. Support and returns forms. Phone photos are large, so allow at least 10 MB per file, and accept HEIC as well as JPEG.
- Certificates and insurance documents. Vendor and contractor forms. PDF and images, and expect a photograph of a paper document as often as a scan.
- Receipts. Expense claims. Almost always a phone photo. Make it required here, because chasing one later costs more than the claim.
- Drawings and specifications. Quote requests. Larger files, sometimes several, occasionally a format nobody expected.
- Signed documents. Where a drawn signature in the form is not enough and a wet signature is required.
Size limits, and what happens when somebody exceeds one
Set the limit at roughly double what you expect. The cost of a limit set too low is a person who cannot submit at all, which is much worse than a slightly larger file.
Modern phone photographs are routinely 5 to 12 MB, and people do not know how to resize them. A 2 MB limit on a form that asks for a photo of damage is a form that half your customers cannot use.
The thing that matters more than the number is the error message. "File too large" is useless. "That file is 14 MB and the limit is 10 MB" tells somebody what to do, and it should appear before the upload rather than after a long wait on a slow connection.
Restricting file types
Restrict to what you can actually open. It stops the submission where somebody attaches a format nobody on your side has software for, and it is a small security improvement.
Be more generous than feels necessary. If you accept PDF for a CV, accept Word too, because a meaningful share of people have only ever had one. If you accept JPEG for photographs, accept PNG and HEIC, because iPhones produce HEIC by default and the person uploading does not know that.
Say which types you accept in the question itself, not only in the error. Somebody who finds out after choosing a file has already done the work twice.
Required or optional
This is the decision with the biggest effect, and the default should be optional.
A required upload loses everybody on a phone with a bad connection, everybody who does not have the document to hand, and everybody who would have given you the information in text instead. On a support form, a required screenshot turns away the person whose problem you most want to see.
Make it required only where the form genuinely cannot proceed: a receipt on an expense claim, an insurance certificate on a vendor application. Everywhere else, ask for it and let people send it later.
A required screenshot on a support form turns away the person whose problem you most wanted to see.
Security and privacy
Uploaded files are often the most sensitive thing a form collects. A CV has somebody's address and employment history; a medical document has rather more than that.
Three things worth checking about any tool you use. Are the files stored encrypted at rest. Is the URL guessable, or does it carry enough randomness that nobody can enumerate other people's uploads. And who in your organisation can download them, because the default is often everybody with access to the form.
Then set a retention period and actually apply it. Holding every CV from every application indefinitely is a liability that grows quietly, and in most jurisdictions it is also a breach of the basis you collected them under.
Practical things that save trouble
A short list of things that are obvious afterwards.
- Allow several files where the case needs it. One upload field for "photographs of the damage" produces one photograph.
- Keep the original filename. "CV_FinalV3_Jan.pdf" tells you something; a random identifier does not.
- Tell people the upload worked. A file field that silently accepts and shows nothing produces duplicate submissions.
- Think about storage. Files accumulate, they count against whatever quota you have, and nobody notices until an upload fails.
- Test on a slow connection. Uploads are the part of a form most affected by a bad signal, and most likely to be abandoned halfway.
Multiple files, and when to ask for them separately
One upload field labelled "supporting documents" produces one document, usually the first one somebody found. If you need three things, ask three times.
Separate fields also tell you what is missing. A single field with three files attached requires somebody to open all three to find out whether the insurance certificate is among them; three labelled fields answer that at a glance.
The exception is genuinely open-ended evidence, like photographs of damage, where the number varies and the labels would be arbitrary. There, one field accepting several files is right.
What happens to the file after submission
The part most people never think about until they need it.
Files should be downloadable from the response itself, so the document and the answers it relates to stay together. A folder of files with no context is only marginally better than the email inbox you were escaping.
If the file needs to reach another system, a webhook can pass the submission on with the file reference, so an application lands in your tracker with the CV attached rather than requiring somebody to go and fetch it.
And know how to delete one. Deleting a response should remove the files with it, and if it does not, you have a retention problem that will not be visible until somebody audits you.