From selfies snapped on cell phones to elaborately staged photographs designed to highlight a craft for sale, you can upload images to web applications for innumerable reasons. Behind the scenes, the web application has to do some processing and storage. Sometimes, the application accepts a variety of file formats and standardizes them, converting them into a single format and creating a thumbnail. Although creating the image might have been as simple as pointing and shooting, testing image uploads themselves is more challenging.

If your company builds such a website, your application might rely on a library, plugin, or service built somewhere else to handle this image management, so your developers might not even know how it works—or even if it works. Regardless of the magic in the box, you should test an image uploader to ensure it works correctly and handles common points of failure.

The Happy Path

In a picture-perfect world, your users will read the guidelines or directions to your uploader and will only send their best images in the common .jpg or .gif formats. Your application will accept them, approve them, and present them in the best possible backlight on LED screens everywhere. But this happy path accounts for only a few test cases. Most tests will come from the gnarled, thorn-ridden paths outside of these.

The Unhappy Path: Image Resizing and Indiscriminate Cropping

If your application consumes photos, it regurgitates the photos in varied ways. Perhaps it only stores and presents the photos in their original glory, including the original pixel height and width. More likely, though, your web application presents the image in other contexts and sizes. Your designers have spent time and effort in building elaborate page layouts. When they don’t have exact control of the images that will display, though—such as when your users can upload their own images—havoc can ensue.

Make sure you upload images of varying sizes, from 25-pixel-by-25-pixel icons to 1600-by-1000 masterworks. Make sure that the images display appropriately and they do not alter or impede page layout. Upload images that are not square; make sure you try 25-by-600 images (a close-up photo of a pen, perhaps) and 600-by-25 images (a close-up of a pen, but turned vertically).

Look closely at the images you upload and make sure that they retain the proper aspect ratio. Your website does not benefit if it looks like it’s displaying standard format images on a widescreen television.

Some applications create thumbnails images—smaller versions of the uploaded images to display in tighter layouts such as tables, grids, or other mass presentation of images. You should inspect how it works. Does the image crop blindly based on the center of the image? Does the thumbnailer stretch the image to make it a square? Can the user select which portion of the original image to use as the thumbnail?

Don’t forget to check the results of the image processing. If your application serves these images on member profile pages or, more likely, in a variety of ways and locations, you should check to ensure the images look right and fit into the page layouts as expected.

The Sullen Path: Common File Upload Errors

As with any file importer or uploader, you’ve got to test certain conditions regarding the upload process.

When the user uploads the file, can your application handle a size of that magnitude? Maybe your user isn’t taking a selfie with the entire deep-field imagery of the Hubble Space Telescope in the background, but your software, services, and databases have their limits. How big of a file can the user upload? I’ve created valid image files in my photo editor with more pixels per inch than most birds can see that have crashed my desktop while saving. I’ve uploaded slightly smaller image files to great wailing and stack tracing of applications under test. What will your application do with a 3-gigabyte image of the text “Hello, world” at 3000 dots per inch?

When the user uploads a file of that minitude, what happens? Granted, it’s hard to have an image at 0 kilobytes, but what happens when you try to upload an empty file with an approved image extension?

Does your image uploader trust that everything with a .gif extension actually contains data outlined according to the Graphics Interchange Format? Your application might be far too trusting. Try taking a text file, saving it with a .gif extension, and uploading the file as though it were an actual image. What does your application do? Does it tell the user anything useful in the error message?

The Morose Path: Image Linking Problems

If your application allows the user to specify file locations on the Internet and doesn’t just open a file chooser for the user to select files from the local computer or network, you have to account for the user linking to files with the problems described above, but you also have other things to worry about.

If you allow the user to type in the web address or URL of a file, anything can happen. The response can include any basic web server response from 404 (File Not Found) to 503 (Service Not Available). Your web application needs to handle all of these error codes—or at least as many as you can trigger—and to display proper responses to the user.

Additionally, many file locations prevent hotlinking of images. That is, some web hosts don’t want to waste their bandwidth acting as a file server for other websites’ images, and if your application tries to poach one of their images, it might deliver some sort of error or a “No hotlinking allowed” image. What does your site do if your user tries to fetch an image from a location that doesn’t want to share?

The Gloomy Path: Problems with Photo Uploads

After considering basic file upload and linking cases, you should learn a bit about image files to glean some unexpected ways your application might run into trouble. Granted, 99 percent of your users will try to upload simple .jpgs and .gifs, but your software should account for outliers in image files and formats.—or your test cases should, at the very least.

I have a thirteen-year-old copy of PaintShop Pro that I use as my go-to graphics editor, and it offers more than forty different extensions for images, from its own proprietary format to outdated (even for its time) file types such as MacPaint and Amiga images. In addition to these complete file types, your designers have a host of different image layers and other parts of completed images that their professional image editors save in temporary directories. What happens when you try to upload a file outside the normal expectation?

As if that were not bad enough, several regular, dependable image types have variations and mistakes that many graphics handlers correct automatically—but your particular image processor might not.

Truncated .jpgs

Michal Handzus played center for the St. Louis Blues National Hockey League team at the start of his career, and no matter where else he’s played or however many times his name is inscribed on the Stanley Cup with other, lesser hockey clubs, he remains one of my favorite players:

This is a .jpg of Michal Handzus. However, it is a truncated .jpg. The file is corrupted about 50 bytes from the end. Most graphics processing applications handle it. You can see it in your browser, can’t you? But some image processors cannot, and whatever error they spit up, your web application must handle it.

Animated .gifs

If you’re old enough, you’ll recognize this as a brief clip from the Norwegian band A-ha’s biggest hit, “Take On Me”:

This is an animated .gif. They were very popular in the late 1990s before Flash and YouTube, and they’re coming back around in Tumblr posts and lists of cute cat posts. What happens when your users try to upload an animated .gif? Also, what happens when your application renders an uploaded animated .gif file? Should you allow your users to upload these mini-skits at all?

Multi-TIFFs

Even my venerated and almost high-school-aged PaintShop Pro did not tip me off to the Multi-TIFF. This comes courtesy of my scanner’s utility package. If you click here and download the file, what you probably see is the front cover of an old paperback men’s adventure novel.

However, this is actually a Multi-TIFF file. Perhaps your application allows Tagged Image File Format (.tif or .tiff) files. But the Multi-TIFF file is like a .pdf file (at least when you’re scanning): After you finish a scan, it asks if you want to continue. As such, the image you see is the first in a series of images saved in the same file. The file contains not only the front cover of the book, but the back cover as well. What does your web application do with this sort of file?

The Rotation of Cell Phone Images

The cameras on cellular phones are tricky bits of machinery. You take a photo or video, you save it to your computer, and you suddenly have to tilt your head to see what displays on the monitor. Your phone captures an orientation value along with the raw stuff filtering through its lens, and that orientation might well differ from how the software presents the file. When your users upload (or link to) cell phone images, the files themselves might pass validation, but does your application correct the orientation or display it awkwardly? To test this, take a series of photos with your cellular phone oriented four different ways and upload the images to ensure they upload and display correctly.

The Malcontent Path: Danger in Photo Uploads

Although the threat is relatively low, some image files can be infected with viruses and other malware payloads. Generally, this requires another infected file to execute the payload within an infected image—for example, see the threat description for W32.Perrun.

Even though infected images might not present a direct threat to your system or your users, your users might have antivirus programs that will scream when they see an infected image file. Your users might not trust your site if it causes a lot of warning messages with big red text that they don’t completely understand. And they might never come back. So, what does your site do with an infected file?

A note of caution in testing these scenarios: Any time you dance with the devil, he might step on your feet. Don’t run these tests yourself if you’re not in a secure environment and you’re not sure of what you’re doing. But do recognize the danger and perhaps use the example to recommend penetration testing and the like for your application.

Conclusion

On paper, images are simple constructs of ink and processed wood pulp. On the Internet and in digital files, however, they present a set of complications and differentiations that you need to keep in mind when your application receives and presents them.

This article presents only a fraction of the test cases conceivable for image-handling software. What other tests do you run when accounting for image handling?