I think I've seen somewhere that only showing the size of a file for download is not particularly useful for some users (in particular those less technical users). I guess the argument for this would be that the size of the file is less meaningful than how long the download will take.

I've seen dialogs which give estimates for download times - does anyone know if this is more useful and if there are any suggestions on how to provide estimates?

It seems to me the meaningful information would be if it's a small file size (trivial download time no matter your connection) or medium (fast on a good connection, longer on a slow connection) or large.


  • I'd give the file size and the estimated download time for a couple of connection speeds like Microsoft does on its download pages. Feb 4, 2013 at 18:04

5 Answers 5


In terms of which is better:

  • Everybody understands the concept of time remaining.
  • Not everyone understands file size.

One minor downfall of time remaining is that it is not 100% accurate. It will calculate how fast your download is currently going, and how long it will take to finish the download at that speed. Because the connection speed will fluctuate, the time remaining will also fluctuate.

It would be good to show both the file size, time remaining, and download speed. Technical users would often like to know this data.

You could display it something like this:

Time remaining: 23 minutes
Completed: 12/147MB
Speed: 1MB/second

  • Ahh, something I didn't specify: the file size is information we provide the user BEFORE they click "download." So the information is there to help them decide if it's a good time to download it now or later (presumably depending on their current location). Feb 4, 2013 at 9:27
  • 1
    if it's on a website, you could estimate the connection speed of the user, while he browses the page. With the found connection-speed and the file size, you could calculate how long it would take to download the file.
    – K..
    Feb 4, 2013 at 11:27

Making the distinction between small, medium and large files makes no sense (nor has it ever) because it depends so much on what connection type your users are on. I consider a 10MB file small when downloading via my DSL line, but I would consider it at to be medium at least when downloading via 3G.

Therefor, I would suggest trying to estimate the time it takes to download the files based on the user's connection to your site/app. But do accept the fact that it's impossible to do a very accurate estimate, as you can read in this great Smashing Magazine article: http://mobile.smashingmagazine.com/2013/01/09/bandwidth-media-queries-we-dont-need-em/

To conclude: try to calculate the speed based on prior site usage and display the estimate, but include a very big disclaimer that this is just an estimate and that the real download time may be quite different.

Addendum: if downloading is a very important component of your site/app, you can think about implementing some connection speed measurement tool like http://speedtest.net offers. But again: that will only offer a snapshot of the current connection speed and depends highly on what other things the user is doing.


File size is critical for users who have paid internet traffic, estimated download time is important for slow connections or large files, so it's a good idea to show both size and time.

I believe that many of users are aware of file sizes because of the smartphones, 3G, "cents for megabyte" etc. So personally I don't see any real problem with this.

Concerning implementation.

I can not find a link to the site I saw this, but you may think about something like showing size of the file and several different estimates depending on the connection speed (or type), like:

File size: 23Mb

Estimated download time: Less than a minute for broadband and 4G connections and Up to 5 minutes for 3G connections.

I think you should limit number of possible connection types to 2 or 3 (of most common connection types in a region, etc). The main idea of time estimation (and size) is to help your users decide whatever they may download file right now or should choose another possibility (depending on their situation) and download it later.

The drawback of guessing on how long it will take for the certain user and certain connection is that you may be wrong (inaccurate) because of different reasons, so, you may estimate download in 5 mins, but in reality it will take 15 mins (because of traffic which start to grow after the download has started, etc) and that's bad, because your user will expect it to end in 5 mins (and that was you who told him that time), so I think it's better to show some average estimates instead. Most of the download managers/web browsers has an estimation build in so users will be aware of download time anyway.


Of course, it depends: what information is useful to the user?

If server space is scarce (like in DropBox), sure, file size is important... but a "time remaining" estimate would be more useful in most cases.

I'm surprised no one has mentioned this yet, but a simple progress bar is the classic intuitive way to visualize time remaining.

Here's how Transmission does it:

enter image description here

Note the color coding of the bars and the small text showing the exact values for more technical users.

This stackoverflow answer and others can help you with the implementation details of calculating the estimated time.

  • And then it gets stuck at 99.8% because no one has the last fragments you need. The progress bar in that case does not show time remaining, it shows amount of data downloaded. Big difference.
    – user
    Feb 4, 2013 at 16:26
  • Ha--I know that feeling, but I'm assuming the question was referring to web uploads/downloads, which are often more consistent. Feb 4, 2013 at 17:48

The reason that file sizes are shown is that it's the only meaningful metric across connection speeds.

It's a rather daunting and, IMHO, pointless endeavor to attempt to predict download speeds...especially once you delve into the world of mobile.

As such, I'd leave it as file sizes. You can't cure all user issues via the UI. There are things that users have to figure out.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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