Protecting Email Addresses Online

June 16, 2009

If you have an email address posted on a Web site, you’re almost guaranteed to get spam. Bots scour the Internet, looking through HTML source code to find email address to harvest. Web developers, meanwhile, are constantly trying new techniques to prevent this from happening. In this post, I discuss an interesting study in spam prevention, some of the available techniques, and the route I choose to go on a recent project.In 2006, a developer created nine email addresses and posted them online, each protected in different ways (or not at all). You can read about this in detail at I love this kind of empirical study, because it uses raw data to prove the efficacy of the approaches. Keeping the email in plain text had the worst result, as you might expect, with encoded and slightly obfuscated versions also being hit with spam. These latter techniques are things like replacing the @ symbol with something less obvious: myname [AT] example -DOT- com. And even if you do try this, you still need to put the actual email address in the HTML mailto link, so that won’t really work.

The most effective results came from using ROT13 encryption, in which the source code has the email address in an encrypted format, with JavaScript then dynamically creating a legible, and clickable, mailto link by decryption. Of course, the JavaScript method won’t work if JavaScript is disabled, but I don’t personally worry about that too much.

There are also two very interesting CSS techniques (this code comes from

<style type="text/css">
span.codedirection { unicode-bidi:bidi-override; direction: rtl; }
<p><span class="codedirection">moc.elpmaxe@emanym</span></p>


<style type=”text/css">
p span.displaynone { display:none; }
<p>myname@<span class=”displaynone”>null</span></p></p>

The first example says that the backwords HTML text should be displayed from right to left order. The second adds an invisible null to the example address. Unfortunately these two routes won’t allow for clickable links and make your site less accessible. Which leads me to a main consideration in this battle: There’s no perfect solution sometimes!

One option that I like is to just use a contact form that sends an email upon submission. This only really works if you have just a single email address associated with a site and it does limit what content can be sent (e.g., no attachments without some extra form work). On my own site, I use an image representation of an email address. But like the CSS methods, a link won’t be clickable and the accessibility is degraded. You can minimize the latter concern by making the ALT tag descriptive, like my first name plus my first initial at this domain. But also keep in mind it’s possible for bots to read images, which is why CAPTCHA text has to be so strange. That being said, I’ve been using this technique for a couple of years now and I don’t think I’ve gotten any spam on that address yet.

Those are relatively simple routes. If you want a really thorough solution, A List Apart has a detailed client- and server-side approach you can try.

As for what I’ve done lately, on a recent Web site I created, dozens of email addresses are listed for the different people involved with the project, so using a contact form wasn’t possible. The project itself involves people for whom accessibility is key, so the CSS techniques were out, too. In the end I went with a JavaScript solution, using jQuery and PHP, which the site is built with. This particular technique—and I have no hard data for how effictive it is—uses a PHP function to create a somewhat-obsfucated HTML source of an email address, then uses a jQuery Plugin to turn that source into a readable, and even clickable, link. For this project right now, it seems to be a reasonable compromise.

Of course, bots keep learning and they’ll figure out how to get around these techniques, which is why we all need to stay informed and try new things. That, and get rid of our email addresses every couple of years!