Site map > Friendly HTML > Images

Creating a Web Page: a Basic Guide

Including Images in the Page

This is one of a series of pages that present the basic principles of using HTML to create a user-friendly web site. This page is concerned with displaying images (drawings, photographs, decorations, etc.) on a web page.


* Principles of friendly web pages

* The structure of an HTML document

* Specifying the layout

* Specifying the typography

* Linking with other locations

* Images

* The src attribute

* The width and height attributes

* The alt attribute

* Obtaining images

* How big should an image be?

* Store images at the size they will be displayed

* How much colour depth is worthwhile?

* Choice of file-type: GIF, PNG or JPEG?

* Organization of web files

* Style sheets

* Refinements: using additional features

* Further refinements: improving accessibility

* Trouble-shooting: why doesn’t it come out as expected?

* Detailed list of contents


You will almost certainly want to include some pictorial information in your pages, whether just decorations or graphs, diagrams etc. that are necessary for fully appreciating the information in the page. These are stored as separate files, often in a sub-directory of the directory where the HTML files are stored. For the purposes of this discussion we shall assume they are in a sub-directory called images. We define where we want to put an image by means of an <img> tag, which has the following form:

<img src="images/redball.gif" width="14" height="14" alt="*">

and as I included this code at the beginning of this section that is why the red ball appears there (or the *, if you are using a text-only browser or you have disabled images).

Let us now examine each of the attributes defined in the <img> tag:

The src attribute

Of the various attributes defined in the tag, src="images/redball.gif" is absolutely necessary and if you omit it then no image will be displayed. It defines the source (src) of the image by supplying its file name and ocation. This will usually be a file on the same server as the HTML file that calls it. In principle you can ask for images stored on other computers, by giving the absolute URL as for a link to a remote HTML file, but in general this is not a good idea, for several reasons. It is bad for you and it is bad for the owner of the remote file. It is bad for you because if the image file is located on a remote commuter you lose all control: if the owner decides to move, rename or modify the file you have no way to prevent it and an image essential for your page may disappear from one moment to the next or change to something you don’t want. It is bad for the owner of the file because each time your HTML file is accessed your server calls the server where the image file resides, giving it quite unnecessary work to do and conceivably straining its capacity to handle the traffic. As a general rule, therefore, you should always copy remote images onto your own server and call them locally.

The next three attributes, width="14" height="14" alt="*", are not strictly necessary as the final appearance of your page on a browser that displays images will be the same whether this information is supplied or not. Nonetheless, it is so desirable to include all three that you should make it a rule to include all of them always. As the reasons for including width and height information are not the same as those for the alt information we shall consider them separately.

The width and height attributes

The width and height attributes tell the browser the width and height – not surprisingly – of the image in pixels before the file has been retrieved. As a result it can calculate the space needed for them immediately and display the surrounding text without waiting for the image to arrive. This is much better for readers because it means they don’t have stare so long at a blank screen waiting for something meaningful to appear on it. You should make no exceptions: include width and height information for every single image in every single HTML file.

The alt attribute

The alt attribute fulfils a quite different function. Not everyone uses a browser capable of displaying images, and even if they do they may have images disabled, as a way of retrieving pages more quickly – a very important consideration for users who do not have fast Ethernet connections. If the alt attribute is omitted such users receive no information about what the image is or whether it is important, and users of text-only browsers such as Lynx just see [IMAGE]. If the alt text is defined, however, Lynx users see this text instead of [IMAGE] and users of graphical browsers with images disabled see a space labelled with it.

Choosing the text to put in the alt text is not trivial and needs to be given some thought. If your page starts with a picture of your company logo it is not very helpful to put

alt=" Company Logo "

This will just prompt the user to ask logo of what company? Much better is to put something like

alt=" Wonderful Widget Co. "

unless of course the text begins with just these words, in which case it is best just to put


This last choice is also best if the image is purely decorative, like the red ball at the beginning of this section, though if it fulfils some minor function such as a replacement for a bullet one can put


instead. If the image has a definite meaning in your document you should try to give some indication of what this meaning is: if you can convey it fully, as for example


for an image representing a Greek letter alpha (though remember that better browsers interpret the entities for these letters, e.g. &alpha; for α, so there is no need to use images) then so much the better, but for more complex images a brief description is better than nothing.

If the alt text consists of one or more words (and not a symbol like *) it is a good idea to put a space before and after the text, i.e. to write

alt=" alpha "

rather than


and often it may be better still to mark off the text more prominently still with brackets, e.g.

alt=" [alpha] "

This will have little or no effect on image-enabled browsers, but it produces a more intelligible display in Lynx.

You should definitely not follow the advice to put

alt=" Get Netscape "

that I saw in another basic guide to HTML. This is just offensive to people who may have perfectly good reasons for using browsers or hardware incapable of displaying images. The sort of people who think that only users with the latest software installed in the latest hardware are worth bothering with will not even see this little gem of humour, anyway, as their browsers will not display the alt text. It is better to put no alt text at all than to insult your potential readers gratuitously.

Obtaining images

Images that are principally decorative – balls of different colours, NEW!, Site under construction icons, etc. – are often already available on the server where you plan to store your HTML files, and all you need to know in order to use them is what their names are and where they are stored. You can find this out from the administrator of your server. You may often see an image of this kind that you like in someone else’s page on the web. Most browsers capable of displaying images also include a command of the kind Save this image as...: you can use this to save a copy of the file on your own disk, giving it any name you feel like. As three different file formats are in common use you need to know which it is: in older pages it was often GIF (Graphical Interchange Format), in which case you should assign a name ending .gif or .GIF, but because of legal complications this is increasingly being supplanted by PNG (Portable Network Graphics) format, for which the file name ends .png or .PNG. Sometimes it is JPEG (Joint Photographics Expert Group), in which case you need a file name ending in .jpg or .JPG. How can you tell? The easiest way is to look at the file name of the original image, which you can find out using the Copy this image location command on your browser.

The next step is to determine the width and height of the image so that you can define these attributes in your HTML . If the original HTML has been well written you can find out the image sizes by means of the View Source command on your browser. Otherwise you can copy the image into a drawing or painting program and measuring its size, or you can do it by trial and error, trying plausible sizes until it looks right.

If you use an image from another web site, do not retain the original link to that site (unless the original web-master specifically asks you to do so), but replace it with a link to the copy on your own server. Why? The principal objection is that linking to an a remote image can add greatly to the work load of the remote server. In addition, you have absolutely no control over what may happen to the image: its owner may replace it with something quite different or just delete it altogether.

Sometimes you will want to use an image that is specific to your own page and in that case, of course, you need to create a new GIF, PNG or JPEG file. To reproduce a photograph or other picture that already exists on paper you need a scanner capable of converting it into a digital form. If this is capable of generating a GIF, PNG or JPEG file directly, so much the better. If not, you will need a utility able to convert one file type to another. Macintosh users have an excellent shareware program available called GraphicConverter; doubtless similar utilities exist for other operating systems. The same goes for pictures you may create yourself with a drawing or painting program: if this is not able to produce a GIF or PNG file directly the initial output will have to converted.

How big should an image be?

It is very important for the readers of your page that the images should not be too big. The bigger the image, the bigger the file that contains it, and the more time is needed to transfer it from the remote server. Remember:

  1. that however fast it may seem when you test it, it will be a lot slower when it is being transferred somewhere else;
  2. that twice as big in linear dimensions means four times the area, and approximately four times the file size and transmission time (approximately because compression schemes used for coding files mean that file sizes are not exactly predictable);
  3. that increasing the colour depth increases the size of the file (see below).

As far as possible you should avoid having any image larger than about 30 kb called automatically by your page. If you feel that it is necessary to give your readers the opportunity of seeing a larger or more detailed version of a picture you should give them the choice, for example by the following type of code:

<a href="images/huge.gif"><img src="images/tiny.gif"
width="20" height="35" alt=" Map of the region "></a>
(250 kb GIF file)

This produces the following result:

 Map of the region (250 kb GIF file)

i.e. it causes the tiny.gif image to be displayed automatically, but marked as a link to the full size image in huge.gif. (You won’t see be able to follow the link in this example, because huge.gif is a dummy label for a file that does not exist.) The user then has the choice of whether the follow the link in order to see the full-size version. It is helpful in such cases to include an indication of the size of the file, as in this example.

The small image (tiny.gif in this example) ought normally to be a small version of the same picture, but this does not mean a link to the same file with smaller values of the width and height attributes. Changing these attributes will indeed produce a different size of image on the screen (with most browsers), but it will take just as long to load as the large image. What you need is a separate and much smaller file. This important point is examined further in the next paragraph.

Store images at the size they will be displayed

 Reduced to one third
*  Original size

Compare the two images shown above. How much difference can you see between them? Probably you will notice a somewhat more jagged outline in the version on the right, and the colours are not quite the same, but if your screen is similar in quality to mine you will see very little difference in resolution between the two portraits. However, your browser will certainly have detected a difference, because the file containing the picture on the left is about ten times the size of the file for the picture on the right, which means that it took ten times as long to load. They look the same size on the screen (assuming you have a browser that allows images to be displayed at a different size from the one indicated in the file), because they are both specified with the same attributes

width="72" height="88"

In this example the practical difference in loading time may be trivial, as both files are quite small (14 kb for one and 1.4 kb for the other), but on the web a huge amount of bandwidth is wasted by transmitting files in much larger dimensions than those that will be displayed. For example, I was looking recently at an image that someone has stored (and transmitted) as a 2057 × 1466 pixel image in a 274.6 kb file, only to be displayed as a 317 × 211 image. This means that the download time could be decreased 45-fold (say from two minutes to less than three seconds) with very little loss in image quality by scaling down to the required size before creating an image file (of only 6 kb) instead of giving the browser the job of scaling it down later.

How much colour depth is worthwhile?

Using 32-bit colour in general produces a file four times bigger (and four times slower to load) than the same image in 8-bit colour, with exactly the same spatial resolution. If you are displaying works of art on your web site you may well feel that this is a small price to pay for a more exact representation of the desired colours, but most of the images displayed on the web look much the same in 8-bit colour as they do in 32-bit, so it makes sense to avoid 32-bit images for most purposes. Even if 32-bit colour looks noticeably better on your screen there is no guarantee it will look better on your users’ screens, because it is quite likely that they are not displaying 32-bit colour anyway.

Choice of file-type: GIF, PNG or JPEG?

If you use picture files that already exist there is not usually any reason to convert GIF, PNG and JPEG files into one another, but if you create your own files then you need to consider which will be better for a specific purpose. As a general rule GIF and PNG files are more suitable for drawings or pictures with large blocks of uniform colours, whereas JPEG files are more suitable for photographs. However, in practice it is not always so clear-cut, especially with photographs. It is a good idea to create various types of file and then examine them (preferably side by side) in your browser. If you can tell any difference, then use the one that looks better; if they look virtually the same, then choose the one that makes the smaller file.

* There is another reason why GIF and PNG files may be preferable. So far as your browser is concerned all images are rectangular, but with GIF and PNG images you can define a specific colour as transparent, which means that instead of being displayed as that colour the background colour (or pattern) of the page shows through. This allows the area outside the limits of the logical picture to appear as if they were part of the background. To illustrate this the red ball shown at the beginning this page has been magnified 5-fold (thereby illustrating how any image is actually composed of little squares of uniform colour, or pixels). Note how the pixels outside the circle appear in the background colour of the page.

So far as these two are concerned, the major reason for changing from GIF to PNG files is that there are legal restrictions on the use of the former.