My android app needs different sized versions of images for different purpose and bandwidth preservation.

Approach one:

  • when the user uploads their avatar or another image, my php script creates 4 versions of that image: mini_200, medium_300, big_400 and original. those paths are then taken and stored in the database. Then, when I need the smallest image, I load it from http://myserver.com/item_images/200_mini_27304lkewsjfimage.jpg

Approach two:

  • same as approach one, but instead of adding prefixes to the names of the files, I store them in different folders - big, medium, mini. and in My app I just pass a parameter for which folder to look in

Approach three:

  • when the user uploads their avatar or another image, I only store the original. Then, when I need the smallest image, I load if this way: http://myserver.com/image_resizer.php?image="93_iosdfj0sd9fj.jpg"&new_width=200&new_height=200

Which one is better and why? I feel like reinventing the wheel here, because this topic is too broad and I dont know where to read about it


3 Answers 3


Your first two options are similar. In your second solution, since you could have two files with the same name in different folders, I would recommend using the size as a suffix in the file name such as images/mini/user_image_1482823_mini.jpg, images/large/user_image_1482823_large.jpg.

Your third approach has an advantage in that it uses less disk space than the other two as well as not needing to manage sets of files and variants for all images, but it must resize images in the fly. This has the potential to cause performance problems if the source images are very large and there are many requests coming in for many different images of different sizes. You could deal with that by caching commonly requested images at different sizes. This may add a bit of complexity the overall architecture of the system, but could be a very good solution if implemented properly.

Since all of this activity would be happening on the server side, I don't thin it would affect your app too much. Your app would only ever submit one image and receive one image. Right?

  • +1 for caching, which will probably eliminate most of the load without having to precompute every version of every image.
    – Caleb
    Feb 10, 2014 at 19:39
  • you mean caching on the server side, right? do you know whether these approaches I semi-thought of are used, and which is the more popular one
    – J. K.
    Feb 10, 2014 at 19:42
  • 2
    @J.Kowalski: Caching on the server-side would mean less work for your server since it can use the cache for frequently requested alternate-sized images. Caching on the client side would prevent a request to the server. Browsers often cache data locally. I think all strategies have been used by different people at different times. I really can't say which is more popular, it probably depends on the context. Feb 10, 2014 at 19:47

You do not want to store static images within a GET query (i.e. a URL with a "?"), as most HTTP caches will not hold on to the results.

An improvement on option 3 would be to use custom routing so that a path like "/images/large/foo.gif" gets interpreted on the server as something like "/resize_image?size=large&name=foo.gif" (see your specific programming language, library framework and web server for details).

A further benefit of this mechanism is that you're now using a regular path structure that's easily shared between options #2 and #3 - the only difference is server-side configuration. That gives you the flexibility to trade off storage space and CPU time to obtain the best balance possible for your application.


It sounds like your third option is the simplest and requires the least storage, but is potentially also the slowest because the server will end up generating the same files over and over. Start with that method, but be prepared to switch to the first or second option if and when you find that the server is becoming taxed.

  • do you know which approach is more popular?
    – J. K.
    Feb 10, 2014 at 19:42

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.