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
The src attribute
The width and height attributes
The alt attribute
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
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
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
<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:
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
calls it. In principle you can ask for images stored on other computers, by
giving the absolute
as for a link to a remote
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
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 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 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. α 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 "
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.
Images that are principally decorative – balls of different colours,
Site under construction icons, etc. – are often already available on the server
where you plan to store your
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
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.
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:
approximatelybecause compression schemes used for coding files mean that file sizes are not exactly predictable);
As far as possible you should avoid having any image larger than about 30
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:
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.
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
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.
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.
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
files may be preferable. So far as your browser is
concerned all images are rectangular, but with
images you can define a specific
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.