How can we go about deciding an appropriate filesize upload limit?

Question

Our web application includes a form where a user can upload supporting documentation. It is anticipated that many users will use the camera on their mobile to snap a photo of a receipt or certificate to upload.

The server imposes a per-file file upload size limitation (upload_max_filesize). Beyond grabbing an array of devices and seeing what size image their cameras output, what factors should go into this decision?

(For example, larger file sizes could slow down submission time for the form leading to an unacceptable user experience, smaller ones could lead to frustration if they're not large enough to accommodate the typical mobile phone camera output.)

Answer 1

We're running a web application and are coming across the same question.

Here are some considerations:

• There is a cost to storing larger files (disk space on a cloud repository or having to move to a larger physical server).

• That cost may be outweighed by the time spent addressing complaints by users (particularly novice or elderly users) who may have trouble compressing or cropping their images to meet the limit that you set on your application.

In our case, we decided to implement a 10 MB limit and sometimes even then, use of scanners in high resolution exceeded this limit. While it's true that mobile use was fairly high, it definitely wasn't the only way users were getting images uploaded. Smartphone photos tended to be in the 2-4 MB range.

If you're in an early stage and don't expect many files, you should consider setting a high limit since you'd likely have bigger fish to fry (like focusing on other UX issues). You can always charge a fee after some threshold is met. Another option is to integrate with an API that will compress your files after upload. There are many available or you can write a quick and dirty custom one. We went with a freemium one.

One other consideration is how you store your files - if your developer stores them as blobs rather than just a path to the file in your DB, your DB can grow larger quickly with larger files (and that can have other ramifications like the DB backup strategy).

Regardless of what you choose, one piece of user feedback we received was to include copy recommending use of file uploads behind a reliable WiFi connection. This way, your users can come back to it when it's more convenient for them, rather than get frustrated on slow submissions.

Answer 2

If it were me, and we're only talking about images, I would start with a file size limit in the 2.5MB - 3MB range and see how well that goes.

My basis for this size range is:

• the most popular smartphone models will take photos in the 2MB - 3.5MB range
• taking photos of receipts and/or certificates will result in less data than your typical family or landscape shot (i.e. file sizes will be lower)
• files in this size range won't take long to upload

You'll soon find out from users whether they're generally having problems with the limit and you can always up the limit later.

Also, with regard to your concern that larger file sizes could slow down submission time for the form leading to an unacceptable user experience, this would only be the case if a user actually tries to upload a larger image. In other words, if you had set the size at 10MB and most users are trying to upload images of around 2MB in size, they're not going to notice any more delay than they would if you had set your limit at 2.5MB.

Answer 3

You're overthinking this problem. It's one thing if you're forced to decide between a 5MB or 5GB limit, it's another when it's between 10MB or 20MB. The truth is, storing static files is extremely cheap nowadays. If it's costing you a lot of money, you're likely doing it wrong. Don't get me wrong, this is a question I've asked myself numerous times, only to be reminded it honestly doesn't matter.

The question you should be asking yourself is why are you implementing a limit at all? The answer to that question will be far more beneficial in helping you decide than simply asking what it should be.

If your average upload is a small image or a scan, set it to 50MB. Worst case? Your users never hit it. You seem to be adding a limit for the sake of adding a limit; so again, I'd ask yourself, why are you adding one? Are you trying to prevent your server from running out of memory due to large uploads? That's a fair reason. In that case, how many concurrent uploads do you see yourself having? If you have a server with 10GB of memory and don't anticipate having more than 5 uploads at a time, 10MB seems unnecessarily restrictive, etc.

tl;dr Answering why you're imposing a limit in the first place is an excellent starting place as to what the limit should be.

Answer 4

First I would say look at the the data. What's the average file size uploaded? What are the outliers? Were the outliers attempts to upload legitimate files? Were users getting frustrated frequently with not being to upload legitimate files? What are the upload limits of your competitors?

If you are worried about the size of the files you can talk to your IT department about setting up a CRON task or even a Gulp task to compress the images after they are uploaded. On a Linux server this can easily be done for images using ImageMagick CLI, and PDFTK for PDF documents.

This way, instead of having users frustrated, you offset the compression your side via task automation. (I would still have a max upload size though to prevent massive uploads).