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.)

4 Answers 4


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.


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.

  • 1
    Overall a great answer, I would only just increase the limit by a multiplier like 30% to anticipate image resolution growth over the coming year or two, as smartphone manufacturers continue to obsess over megapixels. Jun 4, 2016 at 1:36
  • We have some stakeholders who insist that photos from newfangled phones are 10Mb and up, which isn't what we've found in our albeit limited tests. They are asking for functionality to automatically downsize too large files. Looking to find a middle road. Jun 4, 2016 at 12:39
  • 1
    That is the case for a very limited number of phones which are not high sellers. But, as I said, setting it at a higher level won't affect performance for most people whose photos will actually be in the 2Mb - 3.5Mb range. There really is no reason why you couldn't set it at 10Mb to cover your bases - most people will still upload files only a quarter or third that size and will be none the wiser in terms of performance.
    – Monomeeth
    Jun 4, 2016 at 12:54
  • For now we choose 8 MB for photo uploads. As stated, photo file size increased over time. Plus consider their upload speed: 1 MB/s means 8 seconds to wait.
    – Avatar
    Feb 15, 2021 at 8:00

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.

  • The limit is set as a server setting in php,ini : upload_max_filesize. It's a core property of php; not sure if you can omit it. I don't think we'd be able to anyhow because of our "server neighbors." Jun 7, 2016 at 17:04
  • I wasn't implying don't set one at all (sorry if my post came across that way). I'm merely saying, determine why you need to set a limit first. If the only reason is truly because it's a required setting, then pick a large number to make it near impossible to hit unless you have some ridiculous file or you're trying to upload a 5gig .mp4 as your avatar, etc. Rather than trying to decide between 10, 12, or 15MB, just pick 50 or 100.
    – michael
    Jun 7, 2016 at 19:16
  • I think this is the best answer from a UX perspective. I know this forum isn't really for discussing technical implementation, but with the ability to store files cheaply, free inbound transfer on most datacentres and even the ability to compress images in the browser (with the Canvas), there is no legitimate reason that any user should face a limitation.
    – Brendon
    Aug 19, 2016 at 21:13

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).

  • We are still pre-launch, so there's no user data yet. That's the conundrum, how to find that sweet spot that doesn't result in user frustration that interferes with adoption of the app. Jun 6, 2016 at 10:30

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.