Technology that earns its place.

A File Upload Limit Should Be Clear Before the Customer Hits Send

An adult reviewing documents beside a laptop and desktop scanner.
AI-generated photographic illustration; not documentary photography.

A customer completes a long form, attaches a document and presses send. Only then does the site reveal that the file is too large. Worse, the error clears the other fields. A technical limit has become an avoidable second job for the customer.

File restrictions may be necessary. The design problem is hiding them until the point of failure or describing them in terms the user cannot act on.

Put the rules beside the control

State the accepted formats, maximum size and whether the limit applies to each file or the combined selection. If only one document is allowed, say so. Explain any required page count or password-protection restriction that the service genuinely needs.

Use an example appropriate to the task: “Upload one PDF, up to 10 MB” is clearer than “Invalid attachment” after submission. That figure is illustrative; the published limit must match the actual system.

Validate twice for different reasons

A helpful interface can check obvious problems early, but server-side validation remains necessary. MDN’s file-input documentation explains file selection and the role of accepted types; a browser hint is not a security guarantee.

Test the boundary with an allowed file, a file just over the limit and an unexpected format. Also test a slow or interrupted connection. The person should know whether an upload is still running, failed or completed.

Do not ask customers to rename a file extension to bypass a format check. If conversion is appropriate, provide a legitimate route and explain any loss of quality or content. Sensitive documents should not be sent to an arbitrary online converter merely to satisfy your form.

Preserve the work around the error

Keep unaffected fields where safe, identify the specific attachment that failed and provide a retry or alternative submission route. Make the message available to keyboard and assistive-technology users, not only as a brief colour change.

Finally, distinguish “uploaded” from “application received”. If another step is required, name it. A successful transfer is useful only when the customer understands what the service has actually accepted and what remains to be done.