StartBlogWebsite maintenanceHow big do photos actually have to be that you place in the margin or in a gallery?

1. what size?

From a technical point of view, it is increasingly difficult to make generally valid specifications for the minimum or maximum sizes of images on the web. The further development of display technology with ever better display quality on the one hand and ever higher data transmission speeds on the other make both the ever smaller and ever larger display of images possible in a meaningful way, from thumbnails with a tiny 80 pixel edge length to screen-filling photos. However, there are of course technical issues to consider when choosing the right image size.

With regard to the question of image size, a distinction must first be made between the file size and the display size of the image file. Both sizes are interrelated: The bitmap file consists of a certain number of pixels, each of which can have a certain colour value. Thus, after integration into the website, the image takes up the space of the corresponding number of screen pixels - this is the display size. Each of the pixels is stored in an image file with an appropriate numerical value for its colour. Various methods are used for compression, i.e. to reduce the amount of data - this is how the file size is calculated.

Large images look great, preferably with lots of colours and little compression. However, the resulting data volumes are at the expense of the transfer time of the image file. Since the loading time is also an important quality criterion of a website, the experienced web gardener always seeks the optimal compromise of the highest possible display quality with the smallest possible file size.

When preparing image files for publication on the web, it is first important to determine the pixel size in which the image is to be displayed on the screen after publication. If, for example, an existing image is to be replaced, it is advisable to determine the pixel size of the graphic to be replaced and use it as the target size for the new image. (Practical solution, for example, in the Firefox browser: Right-click on the picture -> "Show graphic info". The "Inspector", which is now on board in many browser programmes as part of the developer functions, also helps with information. A screen ruler, such as "Measure-it", which is available as a plug-in for various browsers, also does a good job).

Those who know the final output size of their web graphics and provide the images in this pixel size are generally not doing anything wrong. For a long time, you could always see it directly when images were displayed in a scale other than 1:1 in the browser, whether enlarged or reduced: it always looked disadvantageous, blurred, noisy and pixelated. The golden rule of bringing the graphics to the output size from the outset and not letting the display programme - i.e. the browser - take over the scaling still has its justification.

However, the picture has changed a little in the recent past. The capabilities of the various browser programmes in scaling image files have clearly increased. The enlarged display of images should still be avoided, because in principle the display programme has to invent additional pixels that are not included in the image file - which naturally has a negative effect on the quality. However, the display of pictures in a smaller than the original pixel size succeeds respectably in the widespread contemporary browsers.

But why should images be made available in a larger than intended pixel size if, on the other hand, this unnecessarily increases the file size? This is simply because in times of more flexible, possibly responsive, designs including lightboxes and thumbnail previews, it is no longer easy to determine a clear display size for each image.

It can therefore be necessary and possibly even beneficial for access times to have larger image files - also - displayed in a reduced size (and thus, for example, save time-consuming additional HTTP accesses for reloading larger image versions). The target value for calculating the pixel sizes of web graphics should therefore be the largest required display size for most common applications.

2. which file format?

Once the desired graphic is available in the correct pixel size, the next question arises: In which file format should the graphic now best be saved for display on the web? As you know, the most common formats to choose from are JPEG, GIF and PNG.

GIF displays bitmaps with up to 256 different colours. One of these 256 colours can be defined as transparent. The GIF provides for the possibility of storing automatically running image sequences within an image file, which makes animated graphics possible. The data is compressed without loss, the compression is most effective for motifs with large areas of the same colour and little optical noise.

The PNGThe format knows different colour depths (from 8-bit = 256 colours up to 24-bit true colour), also offers 8-bit = 256 gradations extra for the storage of graduated transparencies and also compresses loss-free.

JPG The 24-bit true colour version widely used on the web can handle over 16.7 million different colour values and the image content is compressed using a number of different lossy processes, which means that the display quality increasingly suffers visibly with strong compression. Transparencies are not supported by this format.

In order to choose the right one from these possibilities, the web gardener first takes a look at the content of the image file. If it is a rather simple graphic motif or even a text element with large monochrome areas and straight, high-contrast edges, as is typically the case with logo graphics, PNG or GIF is the format of choice. The monochrome areas can be compressed well with these formats, while the edges remain sharp and high-contrast. Very small file sizes can be achieved by deliberately reducing the related colour palette.

The JPEG format would produce visible blurring and unsharpness especially at the edges of such motifs within the scope of compression without achieving advantages in file size.

The situation is different when it comes to more complex, smaller and more colourful motifs such as photos. Here the JPEG format shows its strengths and produces attractive image files with a significant reduction in file size. How far you can go with the degree of compression before the quality visibly decreases depends on the motif in question and can be determined by experimenting - or you can simply stick to "safe" moderate compression settings.

PNG is capable of qualitatively equivalent representation of photos, but cannot keep up with the file sizes achieved for such motifs. In GIF, the forced reduction of the colour depth to 256 colours would often lead to visible quality losses.

Example 1: Logo

Logo in PNG format Logo as JPEG
left PNG-8: 3kb, right JPEG: 8 kb. Even with quite strong compression, the JPEG format cannot keep up here in terms of file size. Despite the larger file size, however, it looks blurrier and more blurred than the PNG.

Logo enlarged in PNG format Logo enlarged as JPEG
The 5-fold enlargement of the two graphics makes it particularly clear: clear edges and colour areas in the PNG versus compression mud in the JPEG

Example 2: Photo

Photo in PNG format Photo as JPEG
left PNG: 33kb, right JPEG: 18 kb. The PNG format gets the short end of the stick when it comes to compression.

Photo enlarged in PNG format Photo enlarged as JPEG
Too much colour - Good to see in the enlargement on the left: There was not enough space left in the 256-colour palette of the PNG for the blue tones in the blurred background. The result is coloured areas where there shouldn't be any and tone breaks instead of flowing colour gradations. (GIF gives similar results to PNG in both examples with slightly higher file sizes compared to this one).

3. what resolution?

When scaling or recalculating an image file to the desired output size, a DPI value can typically be specified for the resolution. Which value is the right one for the correct output on the screen? The answer is amazingly simple: it doesn't matter.

DPI (= dots per inch) refers to the density of pixels in the graphic per inch of the output medium. Since the pixels of a bitmap graphic are represented by pixels, the term PPI = pixel per inch is more appropriate. This information is particularly important for printing. A graphic with a pixel size of 300x300 pixels would have an output size of exactly 1x1 inch when printed at 300 dpi/ppi, at 150 dpi/ppi only 150 pixels would be placed on each output inch, resulting in an output size of 2x2 inches. Since the amount of data would be the same in both cases and only the print density would differ, the printed image would be larger in the second case, but the sharpness of the representation would be reduced accordingly.

The output size on the screen, however, has always been decoupled from units of length such as centimetres or inches; what counts here is the absolute pixel size, or a relative value such as the percentage of the available window width. How many centimetres the display ultimately takes up on the screen varies depending on the output device as significantly as, for example, the screen area of a compact mobile phone differs from the 28-inch display.
It is ultimately irrelevant for the screen output whether the DPI field contains the common 72 DPI, or 96, or 100, or 300. Use your lucky number. Or maybe 42.

In summary:

If you want to embellish your web garden with new images, first make sure you know the maximum planned display size of the graphics and scale the image files to this pixel size. The appropriate file format for the output is determined by the content: GIF or PNG with a colour palette that is as sparse as possible are often right for logos, lettering elements and similar graphic simple motifs. For photos, the JPEG format is usually used. The DPI value can be safely disregarded.

See also

Bewilderment in front of the screen: Browser does not display what you want

Help, my Firefox, Chrome, Safari, Edge is showing me old or broken content....

3 August 2020

After changes have been made in the context of website maintenance, we often receive feedback from customers such as "Everything still looks the same on my site" or "But now the website is completely broken!"
What is going on and what can be done?

Screenshot of a homepage application

How to make a screenshot of the complete homepage

20 August 2019

Gerry the web gardener answers the question how to make a screenshot of a complete homepage.

wanted poster: font wanted

What fonts are used for headings and text on our site?

5 December 2019

"That looks nice though, I wonder what kind of font that is? And what colour?" In web development, as in gardening, it is always interesting to look at the results of other creators. Conveniently, the curious web gardener is given all the tools to do so with a contemporary browser.

We will be happy to call you back.

Scroll to Top