Celebrating 20 years online :)
Web Dev + WordPress + Security

Best Method for Email Obfuscation?

Awhile ago, Silvan Mühlemann conducted a 1.5 year experiment whereby different approaches to email obfuscation were tested for effectiveness. Nine different methods were implemented, with each test account receiving anywhere from 1800 to zero spam emails. Here is an excerpt from the article:

When displaying an e-mail address on a website you obviously want to obfuscate it to avoid it getting harvested by spammers. But which obfuscation method is the best one? I drove a test to find out.

After reading through the article and its many findings, here are what seem to be the best methods for obfuscating email addresses displayed publicly on web pages..

Reverse the text direction

According to the article, one of the best methods for hiding your email address from spammers is to write it backwards and then reverse the text direction with a little CSS trickery. Let’s say we want to display and obfuscate the following email address:


We would include the email address by writing it backwards in our web page, and wrapping it in a <span> tag with a nice class attribute:

<span class="obfuscate">moc.noitpecni@kcik</span>

Then to display it properly for our visitors, we apply the following CSS:

.obfuscate { unicode-bidi: bidi-override; direction: rtl; }

When CSS is enabled, this declaration block will reverse the display of any text within the .obfuscate-classed <span>. Works great, but not without a few downsides:

  • Requires the user to manually type out the address (i.e., a mailto: link won’t work)
  • The email address will display backwards if CSS is unavailable.
  • When the user does a copy/paste of the email address, it’s going to be backwards.
  • Bots could probably “decipher” these strings easily if programmed to do so.

Despite these issues, the reverse-text method proved 100% effective throughout the 1.5-year test, so definitely a good method to know.

Add some “null” text

Another effective way of obfuscating email information is to insert some “dummy” text into the email address itself. For example, using our “kick@inception.com” address, we would insert “<span>null</span>” into the address:

<span class="obfuscate">kick@<span>null</span>inception.com</span>

..or even something more complex:

<span class="obfuscate">

With these injected character strings, the markup looks nothing like an actual email address. But we’re not finished with it yet – we still need to ensure that our human users are able to read the correct information. This involves hiding the nonsense <span>s with a little CSS:

.obfuscate span { display: none; }

Simple enough. Again, this works great because users will only see the email address and not the “null” text. This method is effective at hiding your email address from the spammers, but there are some familiar downsides:

  • Requires the user to manually type out the address (i.e., a mailto: link won’t work)
  • The email address will display the “null” text if CSS is unavailable.
  • When the user does a copy/paste of the email address, it’s going to include the “null” text.
  • There may be a bot that can decipher such convoluted email addresses, so be careful.

Serious accessibility/usability challenges, but still another 100% effective method according to the test results.

Encode/Decode with ROT13/JavaScript

The ROT13-algorithm is an encoding method whereby all alphabetic characters are rotated by 13. Similarly, ROT5 is used to encrypt numeric digits, whereby every number is incremented or decremented by 5. This type of cipher is commonly used in Usenet/chat threads.

Using ROT13, we can use a free online tool (or directly via PHP) to encode an email address and then use JavaScript to decode it in the web page. Encoding our example email address, we get this:


We then include this ROT13-encoded address in the web page using this JavaScript:

<script type="text/javascript">
	document.write("<n uers=\"znvygb:xvpx@vaprcgvba.pbz\" ery=\"absbyybj\">Fraq n zrffntr</n>".replace(/[a-zA-Z]/g, 
	function(c){return String.fromCharCode((c<="Z"?90:122)>=(c=c.charCodeAt(0)+13)?c:c-26);}));

That snippet will then display the following markup:

<a href="mailto:kick@inception.com" rel="nofollow">Send a message</a>

..which will create an email link on the page for your visitors:

Send a message

This is another 100% effective method according to the test, with the only downside being that JavaScript is required for it to work.

Other Obfuscation Methods

The test also included a fistful of other methods that varied in their overall effectiveness. Here is a quick run-down:

  • Replacing “@” with “AT” and “.” with “DOT” in plain-text email addresses was also quite effective (but not 100%).
  • Building/inserting the email address entirely with JavaScript (404 link removed http://bit.ly/ImZkc6) was the next-best method, but some spam still got through. Looks like harvesters are learning JavaScript.
  • Encoding “@” and “.” with character entities in plain-text addresses resulted in a significant volume of spam.
  • Splitting the email address up with HTML comments was also ineffective at stopping spam.
  • Encoding the email address with urlencode was less effective than any other method mentioned so far. Email-harvesting bots apparently have the whole “urlencode” game figured out.
  • And worst of all is just using plain-text to display your email address. Definitely not recommended if you hate teh spam!

And, although it wasn’t included in the test, you could also use an image to display your email address, but the accessibility and usability is pretty poor, and there are bots that can interpret image-based text.

So which one of these email-obfuscation methods is best? One of the first three, based on the test results. Generally, these methods are useful for dropping the occasional email here and there, but perhaps the best method is to..

Use a Contact Form

When it comes to providing an easy, spam-free way for people to contact you, nothing beats the convenience of a simple, web-based email form. If you are using WordPress, there are many contact forms available, including my clean and simple Contact Form X, which is Ajax-powered for extra awesomeness.

Of course, form email has its downsides as well. Most notably, it takes longer to set up and test an online form than it does to slap down a line or two of code (as in our previous examples). Another challenging issue that I have experienced is getting contact forms to properly handle code characters (HTML, PHP, et al).

Use whatever works

If you have the time, using a web-based email form is probably the best solution for contact pages, but if you just need a way to simply include an email address, one of those first three methods may be just the ticket for keeping your publicly displayed emails spam-free.

For more information on these (and more) anti-spam email techniques, check out the original article. And, if you happen to have a favorite – and effective – email obfuscation trick, throw down in the comments and I’ll add it the post.

About the Author
Jeff Starr = Designer. Developer. Producer. Writer. Editor. Etc.
BBQ Pro: The fastest firewall to protect your WordPress.

48 responses to “Best Method for Email Obfuscation?”

  1. Blake Embrey 2010/08/24 12:58 am

    Or you could just use a URL shortener like http://gi.vc/ to shorten your email address and put that on the internet. I don’t know how effective it would be, but how many spam bits would follow URLs to see if they are email addresses?

  2. @Blake Embrey: Interesting idea – I may try this on an upcoming project. Thanks for sharing :)

  3. Not just great article but great site and very usefull tips.

    Just a small addon on email obfuscation methods.
    On some sites I made a small flash file with the email address, containing button with full mailto:… link. Graphicaly, it is not problem to fully simulate look and feel of the context around email (regarding font).

  4. Even though not a 100% fool proof idea, I use a mixture of PHP and it’s GD library to create a script which allows me to hotlink basically to using a GET param which is the email base64 encoded, which then returns an image with the decoded text.

    The only downside being uses more resources also some of the more clever bots can read images, so you could always try going the way Captcha’s do by distorting the image, but again still not 100% safe but then again nothing ever is.

    Could be interesting to see what people come up with in the next couple of years, perhaps a nifty little script that opens your default mail client and inputs the email into the “to” section you never know.

    Ps: Great post thanks.

  5. So– how to put the cat back in the bag?? I am constantly getting new clients that have for years left their primary business contact in the clear–and now they want me to try to cut down on the spam.

    Usually, I just tell them the move to Gmail (really good spam filter), but I’ve wondered if you obfuscate an email that is in the wild already is it a waste of time or should you just do it and perhaps in a few years the spam will die down…

    Of course it’s best to convince them to abandon the address, and use one of the solutions presented here on a new address.

    Anyone else figured out a better way to deal with this?

  6. I would NOT recommend REVERSE THE TEXT DIRECTION method because I always copy and paste email addresses if I want to email them something. If they copy and paste and it reverses on paste, they will NOT know it’s invalid. That’s why you get ZERO email… they wouldn’t know it’s invalid once they paste it in email address and send it only to be told it’s undeliverable and that means they think you’re not doing a good job.

  7. Alec Jacobson 2010/10/28 6:38 am

    I like the backwards approach, but the copy-and-paste draw back is too annoying to use it. I listed some techniques on my blog and would be interested to hear what you think: http://www.alecjacobson.com/weblog/?p=1408

    My conclusion was to use javascript just in time (when the user hovers over the link) that way mailto and copy-and-paste still work.

    How did you test the effectiveness of these?

  8. Here’s an online ROT13 encoder/decoder for PHP that takes all of the legwork, err, fingerwork out of it: http://rot13-encoder-decoder.waraxe.us/

  9. PHP Made Easy 2010/11/18 9:18 pm

    Rot13 is great, but it has it’s limitations as it accepts only ascii characters. I recommend base64 encoding. It gives you a nice and compact string that can be decoded using javascript. I wrote a PHP function / jQuery plugin at http://www.php-ease.com/functions/email_link.html that accomplishes this very purpose.

  10. Rune Jensen 2011/01/12 12:28 pm

    Here is a simplified version of the serverside function I use, which seems to be pretty effective. It works for form felds as well. It is in semicode, not actual code:

    function spoofField( ArgIn)

    ‘ validator : Validators
    ‘ bot,crawler,http:// : search engine bots and other (usually) good bots
    ‘ Java : Harvester bots
    ‘ Urllib : SQL injectors/scrapers
    if strings “http://”,”bot,crawler”,”validator”,”java”,”urllib”) is NOT in user_agent Then exit function

    if string “mailto:” is in ArgIn then
    exit function
    else if string “http://” is in ArgIn Then
    spoofField=”MyFakeURL” (I use this for my own honeypot in action attribut)
    exit function
    spoofField=random, gibberish string
    end if
    end function

    You use it directly in your serverside code/HTML by for example:

    Here is my <a href=””>Email address


    <form method=”post” action=”” />


    <input type=”text” name=”” />

    The real script is a bit more complicated, because I have a link to my contact formular as well as a fallback for the email address (among other things), but this is the basics. It can spoof any form field/action field and any email address, and will hide those from search engines as well as validators and scraper bots. Legit users will see the real address and form fields, others will not.

    Since it is serverside, it is not relying on the user having Javascript turned on.

    TIP: Lots of useragents that claims to be IE6 are in fact scraper bots. I have the algorithm for testing this as well (the user agent itself is obviously not enough), but if you implement a fallback, you can test for user agent IE6 and GZIP not accepted, then it is a scraper bot 99.9% chance. Same with Win95, Win98, IE5 and IE5.5.

  11. Rune Jensen 2011/01/12 12:29 pm

    Hmmm… not encoding those HTML special chars, I see :)

  12. Hey Rune,

    I blame it on WordPress! :P

    That looks like some great code though, so if you’ll send me a new copy via email (to jeff at this domain), I can format and replace in your previous comment.

    Thanks :)

Comments are closed for this post. Something to add? Let me know.
Perishable Press is operated by Jeff Starr, a professional web developer and book author with two decades of experience. Here you will find posts about web development, WordPress, security, and more »
The Tao of WordPress: Master the art of WordPress.
Crazy that we’re almost halfway thru 2024.
I live right next door to the absolute loudest car in town. And the owner loves to drive it.
8G Firewall now out of beta testing, ready for use on production sites.
It's all about that ad revenue baby.
Note to self: encrypting 500 GB of data on my iMac takes around 8 hours.
Getting back into things after a bit of a break. Currently 7° F outside. Chillz.
Get news, updates, deals & tips via email.
Email kept private. Easy unsubscribe anytime.