To help reduce SPAM, email addresses on websites should not be readable by programs (spambots). Yet usually for a website to be fully useful, email addresses still need to be readable by humans. The technical solution to this problem is simply to present email addresses as images rather than as text.

Here's an example of what this should look like: the email address for Mr. Somebody is . This address is readable by humans, but not easily harvested by spammers. (The HTML source that references the sample email address image above is <img src="sampleemail.gif" alt="Mr. Somebody" border="0" align="absbottom" vspace="1" hspace="0">.)

The Tool

Converting email addresses from text to images sounds straightforward in theory, but the practical difficulty is producing the needed text images easily and quickly. One way to produce such images is with high end image processing programs, but this is slow and expensive. A better way is to use this simple String2GIF tool for converting email addresses to images. This tool is available to anyone, and can be downloaded directly from right here. (To download this program, you may need to right-click then select "Save Link As..." rather than just left-clicking on the link.)

This tool runs on almost all Windows systems, and its operation is self-explanatory. Just start it and fill in the requested bits of information, and your image file will be written to the location you specify. The image file is "transparent" (except for the text), so you can insert it anywhere in any text with any background without worrying about matching what's behind it.

Details

To prevent harvesting of email addresses by spammers, the email addresses should not appear anywhere at all in the HTML behind a webpage, not even as ALT text and not even in a "comment" within the raw HTML. Email addresses should not be stored as text anywhere on a web server, not even in a non-displayable file or a database.

Although quite difficult, it's possible in theory to programmatically examine an image and turn it back into text. Thus email addresses hidden by the image method are not completely secure; they could be decoded by a program. (Of course they could always be read manually by a human spammer just as they are by other humans.) Fortunately no practical implementation of such a program is currently known. Spammers harvest the easy text addresses and don't try to decode images.

Using this tool, the font face, size, color, and weight of the text image are not controllable. They may or may not exactly match the surrounding text. They're composed using the same alphabet as the surrounding text and are easy for a human to read, so don't worry too much if they look a bit odd in some situations.

The images don't need to be in the same folder as the web pages that reference them. In fact, you will probably want to store all your email address images in a separate folder that doesn't contain anything else. Doing so makes it easy to instruct search engines not to index any of the email address images without affecting the indexing of other parts of the website. The conventional place to keep images is in a folder named "images9", so the SRC= attribute of the <IMG tag may look something like either src="../images9/sampleemail.gif" or src="/images9/sampleemail.gif". Using the "images9" convention, here's all you would need in a robots.txt file (in the root directory of the web server) to instruct web search engines to ignore all the email address images:

User-agent: *
Disallow: /images9/

All this assumes that you've completely abandoned use of the "mailto:" option in the HTML Anchor tag. Abandoning "mailto" —and hence any possibility of already having the To: address filled in when an email composing window is opened so it isn't necessary to retype it— is a small price to pay for reducing SPAM.

Extensions

You may wish to automate the process of converting email addresses to images, and integrate your automation into the maintenance of your website. There are a gazillion different ways to maintain websites and so a gazillion different ways to automate and integrate the email->image process, and so suggestions here will probably be irrelevant to your situation.

If you use Dreamweaver as your preferred tool to create and maintain your website, the most sensible approach may be to cast the email->image process as a Dreamweaver "extension". Dreamweaver provides a lot of extension capabilities. Unfortunately, the best reference documentation I'm aware of, the official Macromedia documentation Developing Extensions for Macromedia Dreamweaver 8 is necessary but may not be sufficient. Despite its length (over a thousand pages!), it doesn't thoroughly explain which kind of extension you want for your need, why, and exactly what parts are needed. The documentation of how to create and use the Javascript->C/C++ interface is particularly cryptic. Web searches are also not very helpful; you will find mostly questions and few answers.

The best companion book I'm aware of that gives a more complete view of these areas is Beyond Dreamweaver, by Joseph Lowery (full title: Joseph Lowery's Beyond Dreamweaver, ISBN: 0735712778). Although it's a bit dated now, I'm not aware of the existence of a better book. I recommend you use a reference book and an overview book rather than trying to choose just one or the other.

Location: N42 40.86' W070 50.35'  (North America> USA> Massachusetts> Boston> North Shore> Ipswich) Time: UTC-5 (USA Eastern Time Zone)  (UTC-4 summertime --"daylight savings time") Email comments to Chuck Kollars

All content on this Personal Website (including text, photographs, audio files, and any other original works), unless otherwise noted, are available to anyone for re-use (reproduction, modification, derivation, distribution, etc.) for any non-commercial purpose under a Creative Commons License.