Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am porting an old eCommerce site to MVC 3 and would like to take advantage of design improvements. The site currently has product images stored in 3 sizes: thumbnail, medium (for display in a list) and expanded for a zoomed look. Right now we are having to upload 3 separate images that are sized exactly right, provide 3 different names that match what the site expects, etc., it is a pain.

I'd like to upload just 1 file, the large one, then let the site reduce it to needed sizes, and I'd like the flexibility to change the thumbnail and list sizes depending on user preferences, form factor (e.g. mobile, iPad, desktop), etc. so might need many copies of the same image. My question is should the image be reduced then saved several times upon upload and if so what is a good storage/naming convention?

The other idea is to store just the single image but resize it programmatically before serving it to the client. Has anybody done this and what are the tradeoffs besides a few more machine cycles? How do you pass a temporary image in memory to the client (there is no URL)?

share|improve this question

I am lead developer for a UK-based travel company. One of the projects I implemented was a web version of our image library which can be queried automatically to provide photography for our site. It contains about 150k images, of which about 60-70k are available to the website (the highest rated).

We started off by defining about 5 sizes, creating these size versions on the fly and storing them in Amazon S3. Price was minimal but Amazon is built to fail gracefully, so we'd often see missing images. The more we developed our site, the more we hated only having five sizes of image available.

We moved to a dynamic resize model, in that we can add width and/or height parameters to the URI of any image to have it render in that size on the fly. We cache the resized image (using an MD5 hash of the request URI as filename).

To get image #12345 (our images are fetched via a db, but you could replace this with a file path) at width 200 and jpg quality 80%, the URI format would be:

This solution was easy to implement and works seamlessly - there is no discernable delay to the website visitor, even on pages with 20-30 images.

We're doing this all with .net, although I've also written a PHP image resize script which does the same thing.

Hope that helps, Adam

share|improve this answer
The funny thing to me is that the "anticipatory resizing" is, actually, a form of caching - just an extremely primitive and limited one. Caching after the first request is the usual approach, and - usually - the better one. The exception is when you'd otherwise be dealing with huge volumes of data all at once, which is probably not the case here. – Aaronaught Jun 23 '11 at 22:38
Brilliant @Adam (that's my best UK-speak), thank you for the thoughtful post. I'm off. – Steve Jun 23 '11 at 23:21

Assuming that the thumbnail is simply a resized version of the main image, then I think it should be done at upload time, but perhaps scheduled as a background job so as not to impact other processes. If you resize on the fly, make sure you cache the image.

The catch in all of this is that the best thumbnail for some images is not a simple resize of the master; you may need to zoom-and-crop in a way that is human-driven. You might want to to the auto-resize thing, but have a mechanism that allows an override in these particular cases.

share|improve this answer
Great idea, thanks. – Steve Jun 23 '11 at 23:18

A slight variation on what Adam has mentioned:

(1) create a custom error page (rule for images)

(2) The structure of the image filenames should be:


The only exception is the original image and should be named:


(3) On file upload eg: 1245_Original -> all files with 1245_* should be deleted

(4) The custom error page (assuming that 1245_Original Exists) should create dynamically the requested image file eg:


and also serve it first time round.

In effect uploading a new image purges the cache.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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