Methods to hide email addresses from page source

Updated: 2006-12-05

I've compiled a list of methods to hide email addresses from the page source to minimize visibility against the email harvesting spam bots. Each method has its (dis)advantages, therefore I leave it up to the reader to decide which method suits them the most, as there are many factors.


<a href="mailto:foo@bar.baz">foo@bar.baz</a>

/* Output on screen */

The good: Since this is the standard way of defining an email address, it is bound to work in any user-agent and has good usability. If the browser is capable of opening an external email client, then it's all for the better. This requires no additional technologies. Unfortunately, email harvesters finds this just way too easy.


/* Output on screen */
foo AT bar DOT baz

There is no magic here, it is very similar to first method as it also contains the mailto href attribute value. Hence, once the bot recognizes mailto: it can easily grab the remaining email. Parsing AT, DOT, and the spaces and converting it to a valid email format is a piece of cake. However, there can be many variations to this idea. Consider: foo[*at*]bar[*dot*]baz.

Unicode characters

/* Output on screen */
foo's email

Not a bad idea, however again it is similar to above methods from a bot's perspective. It can just as easily interpret the special character entities &#64;, &#46; for the @ and the . characters respectively. A minor plus in this case is that, the user may use their email client.

Hex values

<a href="mailto:%66%6f%6f%40%62%61%72%2e%63%6f%6d">foo's email</a>

/* Output on screen */
foo's email

Alternativily, Hex values can be used to hide an email address temporarily. A script that is after emails written in Hex values, perhaps would look at the href="mailto: portion and grab the rest of the href value. A decent method nevertheless.

HTML Comments

foo<!-- >@. -->@<!-- >@. -->bar<!-- >@. -->.<!-- >@. -->baz

/* Output on screen */

The old known HTML comments takes a shot even at assisting hiding emails. Few contributors recommended this solution to be effective, by specifically confusing the way comments work. Placing the @, ., and > symbols inside of the comment makes it a little more difficult. Unfortunately, user intiated mail client can not be brought up with this method.

Fake email

/* Output on screen */

Although this is written, it contains null values which can be indicated (i.e. on a pre made subject) to the user that in order to reach the proper email address one must remove the suggested text. This works well against bots because even though they get the email, it is an invalid one, hence you are safe. On the other hand, it's relatively a nuisance, and may cause confusion to the user, if the idea is not described well.

A variant of this approach would be to use the DEL element:

/*Output on screen*/

HTTP Redirect

Write a server-side script to return "mailto:foo@bar.baz" link as an HTTP redirect. All modern browsers recognise this, but perhaps not many harvester bots do. This can be done with Apache's mod_rewrite, Javascript or server-side scripting. Here is an example in PHP:

/* Output on screen */
foo's email
/* In email_foo.php file */
    header ("Location: mailto:foo@bar.baz");

In this case the user has to follow the link and rely on their mail application to get a hold of the email address. The user has to copy the email address from the application instead of doing it directly from the webpage.


<script type="text/javascript">
    var string1 = "foo";
    var string2 = "@";
    var string3 = "bar.baz";
    var string4 = string1 + string2 + string3;
    document.write("<a href=" + "mail" + "to:" + string1 + string2 + string3 + ">" + string4 + "</a>");

There are numerous ways of doing this in Javascript, however the idea is the same. It allows you to break the email into parts, where it can't be easily parsed from the source. This email method is only visible on screen as it renders on browsers which supports Javascript, or those have turned Javascript execution on. Keep in mind that, Javascript is not available to many user-agents, and has an accessibility issue (see: reaching the audience part 1.) Again even with this method, it is possible to get to the email, but given some creativity it can be well prevented.


This technique allows you to give an encrypted email in the source. With Javascript for example, we can decrypt the email. In the end this is quite a safe way of going at it to hide emails, and is troublesome to decrypt. Similar accessibility factors apply here as above.

Obfuscate AJAX

For hiding emails, we can use a neat Sessions and Javascript trick to md5 an identifier for the email which needs to be hidden from source. In this method a server-side script generates a Session and an md5 value for the email attached to the identifier of an element.

<span class="_obsf" id="17d8910e9b75ab523e5c3a2fc09c1181"></span>
<script type="text/javascript" src="obsf.js"></script>

Following this, browser initiates Javascript onload. This script collects the element(s) with the md5 values as their identifier, and submits a POST request. The compliment of this, in other words, the obfuscated value(s) contain the email which needs to be hidden from email harvesters. A Javascript function then fills in the true email once the page has finished loading.

Example: obfuscate ajax email

For this to work, server-side scripting, Session cookies, and Javascript, must exist. However, given the availability of these futures, along with the considered audience, it is a good way to hide email addresses by storing the email string temporarily on the server, and then calling the value back with Javascript, which then loads the email. Otherwise, its is in high alert in terms of accessibility.

Notes: Thanks to Arpad Ray for introducing his method as an alternative method to hide emails.

Source: Obfuscate AJAX by Arpad Ray


For this technique, we make a small image file, which contains our email address. Email hunters nearly have no luck obtaining the information in the image, unless all arrows are pointing to this image, with the words 'email is in this image, come grab it.' Even in that case, it is very difficult to extract the email address as it requires a special harvester that is capable of getting the content (if its text), from an image file. This is very costy with respect to resources required for the work just to grab an email from an image file. Given the vast availability of email addresses on the internet, harvesters can easily ignore this method of obtaining emails, and stick to simpler forms. Even at this stage in our AI development, specific software designed for this has some difficulty in interpreting the information inside images. Consider styling the written word, where it is easy for a human to understand, but it can be very difficult for the computer.

foo AT bar DOT baz image

Keep in mind that, only user-agents that can render the image properly will display the email address, and there is a great accessibility issue here as visually impaired users will not be able to obtain the email address.

CSS pseudo-element :after

p:after { content: "foo\40bar.baz"; }
<p>email me: </p>

/* Output on screen (\40 is unicode character entity for the '@' symbol): */
email me: foo@bar.baz

Great technique for those browsers that can interpret CSS2's :after pseudo-element. The drawback is that not all user-agents fully support CSS2. As browser technologies progress more browsers will be able to interpret this, however there is always a chunk of users left out; including users with screen readers, and text based browsers. This method is also in the same line as using ASCII characters in the HTML source code.

CSS unicode-bidi

span.codedirection { unicode-bidi:bidi-override; direction: rtl; }

<p><span class="codedirection">zab.rab@oof</span></p>

/* Output on screen: */
email me: foo@bar.baz

The key in this method is to change the direction of text from left-to-right (default) to right-to-left. This method is one of my favourites, since this CSS unicode-bidi algorithm is supported by more browsers. This method will display the email backwards for those user-agents without the CSS features, which could be bothersome to invert.

CSS display be none

p span.hide { display:none; }

<p>foo@bar<span class="hide">null</span>.baz</p>

/* Output on screen: */

Yet, there is a third method to hide emails using CSS. In this case, we just remove some null text from the body of the email with display none. This property is largely supported.

If the bot script does not parse through the CSS, then the techniques above can be handy to hide email, otherwise the email may face the possibility of getting spam. Although, not overly difficult to build these scripts, they take longer time to process the stylsheet data, which may or not be a worthwhile exercise.

Again, same accessibility issues as the previous CSS technique apply here. Also the good thing with these CSS tricks is that, they are visible on screen, and can be selected and copied to the clipboard. The email is textually available to the user, however they can't click on the link in order to open their email client.


One can also use Flash to hide emails from spammers. In this case we create a flash file that simply loads a browser function getURL() with mailto scheme. In addition to this, place the following HTML.

<object type="application/x-shockwave-flash" data="media/flash/articles/email.swf"
    <param name="movie" value="media/email.swf">

Which gives us:

So, how could an email harvester find the hidden email in this flash file? One way would be to decompile the flash file. Once the source is available, parsing towards mailto and grabbing the email would be the easy part. We have to give consideration to cost of such task as it can be quite expensive. Finding, fetching, decompiling, selecting source, and finding the email address for a flash file is a lot of work. For a general sweep on the internet, it is much easier for the email spammers to look into other methods. Therefore, Flash also be a useful way to hide emails from spiders.

Needless to say accessibility issues rise up with this method, as not only certain UA's do not support Flash, but there is also the possibility of this component failing to load for any reason. For sites that have a focus market (in regards to Flash being present) then I think this is quite sufficient to hide emails.


<form action="emailmessage.php" method="POST">
    <legend>Contact information</legend>
    <label for="fullname">Fullname</label>
    <input type="text" name="fullname" value="" id="fullname" size="50" maxsize="50">

    <label for="email">Email</label>
    <input type="text" name="email" value="" id="email" size="30" maxlength="50">

    <label for="message">Message</label>
    <textarea name="message" id="message" rows="5" cols="30"></textarea>

    <input id="submit" type="submit" name="submit" value="Contact me">

This is a very widely used method since it reveals no email address. Since the email is not in source, it is neither available on viewport. Therefore, the user has to contact you by filling out a form, which eventually gets forwarded to your email. There are some alternative methods to this, where the email is actually accessible if the actioned value is a cgi file and not complex enough. Be careful with this since it technically brings us back to square one. A server-side scripting process for the form values is very safe, and the email spam bots simply pass this source area as it contains no email. A disadvantage for this could be the comment spammers, where they leave their mark on your form, which you might have to put up with later. But that's a different spammer all together.

The Question!

This method gives you the chance to reveal your email only to human users. Basically, you can have a form that asks the user a simple question. What is 5 plus 7? If the user submits a correct answer to the question then you can reveal the email address as simple as the plain method. The user has to take the few extra seconds to go through this, but email hunters have no luck with this method, since there is no way for them to process the question, yet alone know that the close-by text is the gateway for the email. This method can be done with client or server-side scripting. If client-side all the mentioned cases on previous methods apply here as well. An alternating set of simple questions would be ideal.


First of all, please note that there are many variations to above methods and they can be combined to produce an offspring. The CAPTCHA method for instance is a combination of using images and a question to respond in reference to the image that is displayed. Nevertheless, the ideas are generally similar in nature. When using any of these methods, some care is necessary. For example, in the Javascript method to put together the values we may overlook the fact that the variable in which the email is contained is in plain view. This defeats the purpose, since the parser goes through everything in the source.

One magical spam script? Another point which perhaps needs to be reiterated here is that all these methods can be a victim of some clever script, by going through a large set of methods, where they could be decompiled, decrypted, or even ran through image analyzers. If such email harvesting bot exists, no doubt the emails can be stolen. Having said that, the goal in developing such methods is to fight against resources such scripts are allocated within. The complexity of such script would be too expensive 'just' to grab an email address from a page. Consider the size of the source code and multiply that by the number of sites/pages a bot has to go through in order to have a good number of emails collected. With minimal measures, a greater portion of harvesters can be fooled.

Most of the methods mentioned in this article present a way to hide the emails from the source code. However, using images, and changing the actual email deal with the visual aspect of the email on screen. Keep in mind that most of the email harvesters are built to scan the source, and to a good degree, they cannot pass the well designed methods. You may ask, what about screen/output email harvesters? Against them, your possible methods are inverted as you need to reshape the visual aspect of your email. Additionally, considering the methods that heavily depend on the way HTML works, in other words how browsers render them on screen then a spam script can merely mimic this, create a temporary output file, and then parse the remaining result. Possible? Most definitely. Worthy? This question may be more difficult to answer.

Again, thank you for all your suggestions, and please keep them coming in order to achieve a solid comprehensive list of methods to hide email address from spam bots. Our goal is to have a diverse set of these methods, and then to select an applicable method. I will update this article from time to time to reflect anything else we might can come up with (see Update date-stamp - a few pending methods will be added as soon as I get some free time. Thank you again for contributing.)

All these methods have their pros and cons, and the method you pick is entirely up to your case - always keep your audience in mind.



101 interactions

sprint replied on

Flash! If you have access to PHP, you can create a form in Flash and send the email address also from Flash to the PHP script. Otherwise, take a Flash button that contains the mailto: order to open the email client.

trovster replied on

Personally I use a form and so do a lot of websites I've visited. Although it's nice to send an email in your client, or via your webmail, it's becoming a necessity to use a form to stop spam. And after a while it's no different or more of a hassle. Maybe less than a hassle in fact as you don't have to open a new window/message to send. It's all contained on the current page you're viewing.

If you must present an email address, make sure you've sent up spam filters on your inbox! I would suggest using a contact form aswell as an email address, so the option is there to use either. How you present the email address then would be up to you. I would see if there is a combination of the CSS unicode-bidi and Javascript, so it works when clicked or copied.

guenter replied on

What do you think of this method:

HTML source standard: E-Mail

source encrypted with UniCode: Hyperlink Text

How smart are these grabbers to interpret this? (Online tool for unicode-encryption can be found here, in German:

alex replied on

guenter, this is the same method as described in method iii. spammers can easily replace unicode characters with "real" characters.

juergen replied on

concerning "vii. Images" and accessibility: it should be enough to only show the "@" as an image - with, of course, an not to obvious name for this image...

Bat replied on

Cool Cleveland, a weekly online newsletter in Ohio publishes email addresses thus:

This is straight text, not a clickable Mailto function. I suppose user agents can be trained to look for this variation.

Bjrn’s photoBjrn replied on

i linked this site on my blog, because i wrote a similar tutorial some days ago that is not as good as this one here. thanks for your good job ;)

Emil Stenström replied on

Another option is to link to a .php-script that spitts out random e-mail adresses. This would probably trigger some kind of protection on harvesters and get your site "banned"... could work :) Nice article, it's good to have everything on one place.

Mathias replied on

I once read that all these complex methods, trying to hide from spambots, are mostly not needed. a simple obfuscation like (my addres) should fool most bots. The reason was that the bots doesn't need to be very clever considering all "open" addresses out there. It doesn't pay off.


TAG replied on

Using REMOVEthis in username portion of email is lame - as all email validators can validate domain name and this will be valuable information for them.

It's much better to use REMOVE this-like portion in domain name. like

Bob Houser replied on

Don't forget to link to some of the better form software out there. I have used this on on my site and it works great:

khansen replied on

Another suggestion: HEX encoding.

ASCII: me@mydomain.dom

Hex: Email me

Here is an example of a perl script that will convert ASCII addresses to hex:

#! /usr/bin/perl
# Little perl program to convert ascii email addresses to hex
# to avoid spam harvesting from mailto: tags
my $addr = shift or die "usage: $0 email\@address.dom\n";
$addr =~ s/(.)/ sprintf('%%%2x',ord($1)) /ge;
print "$addr\n";

As documented at:

Chapter 2, preventing unwanted SPAM.

The issue as I see it is to try to confuse the bots while not confusing the humans.

Derek Martin replied on

On Saturday my blog received over 1000 spam comments, so I decided to do something about it and whipped up some "whitelist" functionality.

Email addresses are essentially pseudo-random strings of characters. I do not show email addresses with comments, but each comment has an associated email address. Each comment has an approved (boolean) field. Each comment has a verified (unique) field.

When you post a comment, I check to see if there is a previous *approved* comment with that email address. If there is, your comment is immediately & automatically approved to the live site.

If there are no previous approved comments using that email address, you are sent an email asking you to click a link to verify you're an actual human, and not just a bot. When you click that link, it passes the unique verify code & commentId via the GET querystring, and you essentially approve your own comment, thus adding yourself to the whitelist. BUT upon this verification I have the site notify me that someone has verified for the first time. In that email I am shown their comment, and given the option to delete it and remove them from the whitelist to prevent future automatically approved comments.

If they used a fake email address, they never get the verification email, and their comment is never seen.

Finally, I do send copies of all verified & approved comments to myself, so I don't have to surf my old entries to find them.

It's working great so far.

If you have any questions, feel free to email me at my first name, via my email-domain,

phreq replied on

Anyone ever try the enkoder form from automatic labs? Search for enkoder on your fav se. Not sure how it ranks but seems pretty sweet.

boesman replied on

Thanks for a great overview.

Off-topic: Avoiding spam is good and well but I've become a lot more casual about it since my ISP implemented the most diabolically elegant and effective anti-spam measure on their mail server. Simply put, they ignore all first smtp connect attempts from unkown ip addresses, and accept the connection if attempted a second time. It relies on the fact that most spam bulk-mailers use a fire-and-forget approach, i.e. ignoring all errors and moving on to the next address (of millions). My spam fell from dozens per day ... to 1 or 2 a month. More info here:

How about an equally comprehensive overview of spam control mechanisms and their true effectiveness?

walkingcrow replied on

Great overview, but like the last comment having a good anti-spam email service is recommended.

I recommend TUFFMAIL ( I get a secure (encrypted transport) service, along with a very effective anti-spam policy which has cut spam out of my life for good (1-3 every couple months).

Check it out.

phil replied on

I've been using the enkoder. It produces a rather large javascript to scramble the mailto, but what appears on the screen is a plain email address. It displays a line that says "Javascript must be enabled" if java is turned off or not present. So far, so good. Creating the encryption is VERY easy!

Nigel replied on

I have used a JavaScript solution with great success. Basically:

[a href=""]contact me[/a]

It's a little more complicated than that but that's the essence of it. The href takes you to a contact form if your browser can't execute the onclick function.

Sometimes I concatenate the email string in a script: writeemail(prefix,suffix,domain...) and provide an alternate method in noscript tags: contact[at]domain[dot]com

Magnus replied on

Using an image is also great if you also want to reduce the numbers of emails sent. People is to lazy to type in the adress themselves. They rather just copy/paste or click. And the emails you still get is the important ones.

jim replied on

I'm a fan of using the forms partly because then your reader doesn't even need to load up an email app (though this could be seen as inconsequential).

drdrang replied on

I've used CGI scripts to hide addresses while still giving visitors the ability to click on a link and open their mail program. The links look like this:

email me (

and the CGI script looks like this

print v76.;
print v109.;
print v110.;
print v112.;

where I've used Perl's v-string notation to obscure the address even in the script (which I suspect is overkill). The script prints out


with two newlines at the end. This directs the browser to the mailto: link, which in turn opens whatever mail client the browser is configured to use.

Ted replied on

I am using encryption in a way that leaves a pseudo address, so the spam harvester wastes their resources on non-existent addresses. I do this by not encrypting the '@' or the '.com' or other top-level domain.

If javascript is not enabled then the image method works well, note that PHP is great for dynamically creating images from text if you need to do so.

Richard Barnet replied on

I noticed that you don't have an example of a true encryption scheme (using keys and what not). This script:

has you pick prime number keys, then RSA 10-bit encrypts your email address.

Crack that, spambots!

MagDealer’s photoMagDealer replied on

My favorite solution is one not described here using normal html comments: foo<!-- >@. -->@<!-- >@. -->bar<!-- >@. -->.<!-- >@. -->baz

When displayed on screen it will look like this: foo@bar.baz

The comments in the html obscure the formation of the address and I've found that putting the special symbols @, ., and > inside of the comment will make parsing the comment out more difficult.

Sean McManus replied on

The CSS text-reverse trick is stylish but also breaks accessibility guidelines. To be confident the email address is accessible to everyone, you would need to avoid images (except with meaningful alt tags), Javascript and dependence on a stylesheet to make sense. Accessibility guidelines would also rule out most simple CAPCHAs because they depend on vision or hearing to work. Although spam is a big problem, we shouldn't allow it to drive us to excluding people using assistive devices. Properly marked-up forms might be the most inclusive way forward.

a person replied on


Calling someone's suggestion lame is unnecessarily inflammatory and doesn't encourage discussion.

Consider that getting lists of domain names is easier than web harvesting, so obscuring domains in one's web publishing is quite lacking in effectiveness. Not long after I register new domains I start getting spam to guessed accounts. Fekkers didn't get those addresses via web harvests.

If you're talking about domains more technically, meaning subdomains, you could try to keep those obscure since they're not published like registered domains. But I didn't read that as your point.

The REMOVETHIS methods are sadly burdensome. The whole having to cope with harvesters thing is sadly burdensome. The whole spam thing is sadly burdensome. Keep in mind that greed hurts everyone.

Many thanks to Sarven Capadisli for offering this well-detailed and described summary.

Susan Snipes replied on

I prefer and recommend the php form method for my clients (method xiv).

Besides keeping the spam bots away, I think it has many other benefits: - professional looking - it doesn't require an email app (great for the MANY web email people) - can help guide visitors in how to communicate with you (when including other form elements for options/interests)

Thanks also for the reminders about accessibility problems using "images" (method ix).

Paul Harvey replied on

I just put this on the last line of my page: "Trying to find my email address? Well, you know my first name, and my domain name... I'm sure you can figure it out. ;)"

What do you think of this?

pogdesign replied on

Best way I've found is changing the email address to ascii (even the mailto: bit) and not putting your email addy on screen. So the text reads "click here to contact us" and the mailto: link doesnt look like a mail link until its parsed by the browser.

I use this on a very busy site, and only get a couple of spam mails a week (probably human input).

I use one of the text to ascii sites out there. Simple and quick.

bandi replied on

I think you should've mentioned the mixture of javascript and written styles: you put in the text written, then transform the pseudo-adresses into real adresses with mailto: links

dave buster replied on

I'm surprised the article didn't mention khansen's (above) HEX technique. I've used it to great success.

JC replied on

Why go through all this when you can just write your email like this


replacing @ with [at} and no link.

Chad Cloman replied on

I like the method at this link. It's a PHP script that outputs a javascript script which uses the eval() command to interpret some escaped (javascript unicode?) characters. The resulting HTML is quite cryptic.

bernd replied on

Why bother at all?

First of all: Every technique used might hurt customers, since there is no guarantee that they can use the mailto: link afterwards without problems.

Second: Spamfilters are quite good now. So deal with it on your side, not on your customers side.

jacob harvey replied on

I like Derek's method for handling comment spam, that's similar to what I do besides the authentication email. Mostly I've found that my method only really allows manual entries of spam, and then with the email I recieve I can delete that comment with a couple clicks.

And that spam blocking boesman mentioned is pretty nifty.

Form is probably the most effective, accessible method.

I've used the enkoder and it worked fine so far. But what I usually use on my site is a javascript function. Instead of giving the bot all the information in one place. I pass some basic info to the function which assembles everything when clicked.

Perhaps I should extend this to "normallly" use the function, but without javascript a click would load up a form to send an email...

Thanks for the article. :)

sisco replied on

I use this hex encocder which encodes the entire html code for the mailto tag. Never had any spam problems.

Tim McCormack replied on

I use the encoded-@ method and it works beautifully. Here's why: Spamming is a bulk market. If my bot spends twice as long looking for those few @-encoded addresses or other variants, I'll get less addresses overall. And that hurts my business. Frankly, there are so many completely unhidden email addresses out there, they may never need to rewrite their bots. All they'd catch for their trouble is a couple of savvier web users, who are in fact less likely to respond to the spam anyway.

a hack replied on

Some of these are very creative. But personally, I don't think it matters how you try to scramble the address, if it's interpretable, it can be scrapped programmatically. In fact, these are now available to anyone who wants to write the program to beat any of these methods.

Bottom line. Use a form. Yes it has drawbacks of possibly not getting the user's correct reply address. However, they offer security from spam, feedback, a minimum of standardized input to make it easier for you to recognize where the email originated from and more.

Johan replied on

I think the automated labs enkoder is really a superb e-mail enkoder!

Only you can easily comment *what a large JS is produced here*

But you can put in a enkoder.js and just put the functionName(); in script tags where the e-mail needs to appear in the HTML

Matt replied on

How many bots are still in use ? is it not just as easy for spammers to assume E-Mail address's exist ie fred{at}

spammer can see bar.baz as a domain so just adds fred, mary, ringo, foo etc at the begining. I use and after 10,000+ spams have had maybe 10 or so that should not have been filterd. I think the ability of anyone to create E-Mail address's is what needs changing. Just like we need to apply for a phone number we should have a system for handing out E-Mail address that stay with you for life regardless of your IP host. accountability would be a step forward.

Richard replied on

I get tons of spam, but none to the address I have on my website. All I do is, I give the address as text [not linkable]. I've been doing this for years, with not one piece of spam yet (to that address). Is this not a simpler method than those described in Sarven's excellent article?

yayo replied on

Nice page. If you take a look at my website (page ) you will see another interesting way I found to show an email address using only an html table. (I'm referring to the 1st one displayed.)

bye. yayo

a visitor replied on

If you have enough budget, go for an e-Mail Forwarding service that has a capability of filtering those SPAM harversters. Create a FORM that sends all requests/feedbacks to that address. They shall get forwarded to your MailBox. Don't forget to get a good ISP that filters SPAMS too. So you get double filterings. Or else, combine HTML+CSS+JavaScript+[Server Side Scripting]. They're all available on this article. No thing is a "Perfect-10". If no CSS, you got JavaScript and/or Server Side Scripting and vice-versa.

Frontier replied on

On my page I use the simple rot13 javascript encryption from

and it seems really good. But I wasn't happy that people eithout javascript couldn't read it at all. Like those with screen readers or lynx.

So here's my solution: have the

[script] elements around the javascript code.

Rot13.write('rot13d email address with mailto');

Then put [noscript] elements around a link free readable obfuscation like: mail to: foobar At this domain

This makes it so that if javascript is enabled, you only see a working link, but if it's not, you get enough info to figure it out.

This seems to me like a good way to do it because it complies well enough to w3m and is transparent for people with modern browsers.

For the [noscript] bit, use the most bloated human-readable email hider in the world to generate a random-text logo of the email address, which uses inline CSS to shrink it down to resemble normal text. This will still be visible even with javascript and images turned off.

Eric replied on

You can combine the encoding method and the JavaScript method for a mask that's virtually unbreakable:

function email() {
 if (!document.getElementsByTagName) return;
 var anchors = document.getElementsByTagName("a");
 for (var i = 0; i < anchors.length; i++) {
       var anchor = anchors[i];
        if (anchor.getAttribute("href") &amp;&amp;
            anchor.getAttribute("rel") == "email") {
            anchor.href = "mail" + "to:" + 
                   "%79%6F%75%" + "%40" + 

Add this function to an external JavaScript file, include it with your HTML document, and put in the body tag. Now write all your contact links like this: <a href="contact.html" rel="email">. If the user has JavaScript, they will see a mailto: link. If they don't, they will see a link to your contact page. This is XHTML-compliant.

robin’s photorobin replied on

Thought you might like to know that I referenced you here:

Thanks for your work! If I'd read it in time, I might not have done my article.

Trevkin replied on

Though a laudable effort i fear this is all a little pointless. This has probably been mentioned but if you are using your own domain in a business context. The spammers will just throw random commonly used prefixes at it anyway. eg. if my site were then any spammer worth his salt will try

etc even to the point of harvesting common names from the about us section of the site and using them as prefixes too. Think i have depressed myself now, boo.

Paul replied on

Well I I've been using a js script to obfuscate my email for years and they work! Personally I think that the really complex ones that encrypt your email aren't all that useful since even the simple ones require a human to figure out the logic behind them and anytime ia human is involved all they need to do is click the link to see what email pops up in the email client.

Anyway, I created my own, free email cloaking script for folks to check out.

BTW, I often seperate my email addresses by a dot, eg: The extra dot also throws off the spam trollers and makes it harder for the auto-generators to guess your prefix.

Tobias’s photoTobias replied on

Something I have found is to enter the mailto link at Then, I simply link to the tiny URL, which redirects to the email address. Works great, and is SO easy.

jule_ replied on

Nice article, thanks a lot!

Another method to display your email-address without harvesters being able to recognize it is CSSfont:

Mischa replied on

I like Tobias TinyURL Solution. Are there any disadvantages? Isn't it supposable likely that email-spiders follow all the links in a page with the goal to find new addresses at the target pages? If that was so they would grab the "tinyurled" email address, isn't it?

somebody’s photosomebody replied on

Another tactic is using .htaccess to password-protect the webpage containing the e-mail address.

How this works: Your website has a page to the e-mail address. You tell your visitors that when they enter the page, they have to type a password. Once they typed the correct password, they can see your e-mail.

How many automatic e-mail harvestors would be smart against that?

Johari’s photoJohari replied on

I usethe form (with no email address) quite a bit, as in most of my situations a customer benefits greatly from being directed by the right questions, as opposed to an open, free-for-all email.

However, I do make sure to send them a copy of the email when they submit it, with a reply-to address.

This opened the possibility of harvesters being able to collect my reply-to address so I added an extra, hidden field into the form that must be left blank for the email to be considered legitimate. Most harvesters that fillout form automatically will fill in every field.

Seems to work well.

Hans replied on

Hello, which e-mail address is "relevant" for spam bots? Is it the link ( or the text - or both?

Joe replied on

Forms seem popular, however aren't there similar problems with those - trying to find accessible captchas?

Pete Victor replied on

I think a good approach is to offer the user both form- and link-based contact options. There are good security advantages to forms, but when I'm the user, I like to have my message in my Sent box and to actually know the address I'm sending to.

Holly Wild’s photoHolly Wild replied on

Is there any script in the frontpage form format that i can use to stop hackster who have harvested our e-mails? We get so much spam. Does this in anyway effect real mail we should be recieving?

Kevin replied on

Great article, I found this site that obscures you email address using CATCHA.

Lee Newberg’s photoLee Newberg replied on

How about using form technology as follows?:


The cgi script returns a page with the e-mail address plain as day. Perhaps spambots aren't daring enough to submit forms. This is exceedingly old technology (no Javascript, php, etc.) and should be accessible to darn near everyone.

Nicolas replied on

A long long time ago, when I started using the internet, spam didn't exist. I decided to buy my own domain name. Then I got spam, but it was too late to hide. My address is everywhere, and I would have to change it, with all the trouble that would cause me. So I'm keeping it, and I don't mind putting it in clear everywhere. I have a spam *fighting* system doing a very good job.

Ah, I also leave randomly-generated addresses in the source code of my pages, to collect spam for my spam fighting system :)

It is working pretty well!

Wojciech Bednarski’s photoWojciech Bednarski replied on

Interesting idea is changing a part of email address every year, and put it in a code normally as plain text.

For example for this year: 2007foo@bar.baz

About CSS unicode-bidi; it is funny, because when you mark and copy email address you get revers text. Exactly like in the code :- )

John Ortt’s photoJohn Ortt replied on

One other possibility is to use a short term address which changes regularly, i.e. and simply reply to all legitimate contacts telling them to use your real address in future. Then you delete the e-mail forward in July.

Mekett’s photoMekett replied on

Note: my Opera 9.23 doesn't handle mailto redirects :( And it doesn't display the content, I send after the redirect header. (For example an anchor tag with the email address.) So I need to watch the USER AGENT string...

Andrej Upits’s photoAndrej Upits replied on

Here is a technique I ran into recently

Evan’s photoEvan replied on

Here's a little diddy I put together:

    function protect(name, address, display){
        var link = name + "@" + address
        if(!display) { display = link; }
        document.write("<a href='mailto:" + link + "'>" + display + "</a>");

Then, in the body copy, use this script in lue of a "mailto" call:

<script>protect("evan", "waetzman", "email me");</script>

This writes the code in the DOM & the front end user can't see a difference (looks like a regular email link). The spiders don't see anything. The 3rd line in the script makes the "display" optional. If you don't put something in there, it'll default to the email address. This has been cross browser/cross platform tested.

Hope this helps -


David replied on

Evan, I like your method but the end of the email address (.com, .org, etc.) seems to be missing from your code? Though it can be easily added I think. I suppose you could also add a subject line "tag" as well.

Also, there's no need to designate what type of script is being used, like javascript?

Best, David

Darren’s photoDarren replied on

If your using php you can use the Ming library => to create flash. I belive that php5 here comes with it packaged in => You could create a simple button and text to create the mailto link. They have a simple example at the bottom of that page at the site link above.

Justin Zajac replied on

Great article, thanks! ...just a word of caution: The HTTP Redirect method does not work in Safari 3, because it won't parse a Location header that contains ":"

Instead, you'll get the following error in safari:

Safari can’t open the page “” because it cannot redirect to locations starting with “http:”.

Graham Cameron replied on

Look at the source code of this page below. A multi-pronged approach that would appear truly bullet-proof to bots:

Look at the source code, and notice the results of a cut and paste on the email address.

Justin Zajac’s photoJustin Zajac replied on

There's also a gotcha with the Hex encoding method.

Google converts the hex back to the original text when it indexes your site, so the naked email address will appear in both the google listing for your page, and the google cache of your page.

Peter replied on

thanks for all the hints and tricks... great to have all in one spoot, much appreciated!

me and my friends have been using 3 diffrent scripts apart from a contact form with "captcha" with great result...

my personaly favorite is "Email Protector" linked over to contact form for those who dont have javascript enabled...

Email Protector by Jim (RSA encryption 10 bit)

The Enkoder by Dan

Email Address Munger - Email Address Encoder

// Sweden

Tuemmel’s photoTuemmel replied on

Hi there,

I didn't know there're so many ways to protect email addresse on the web.

However, using the javascript version above, I've written a prog that converts the email address into ascii-code.

For better protection the email address and the ascii-letters in a letter-array are also splitted and mixed up with some randoms.

This might sound complicated, but it's not since there's a form available that generates all encrypted htm(l)-files, pictures of your email address and an external javascript file automatically.

All you have to do is to choose the picture style and throw your page into the program.

After encrypting you'll receive the encoded files to download. So that's also for ppl who are not so qualified in programming.

Hope it will help someone.

Cheers Tümmel

Namdnal Siroj’s photoNamdnal Siroj replied on

I think that once your website is visible enough to spammers, they will just spam you at info@, mail@, etcetera. Hiding the emailaddress is mostly about hiding the domain name, and they already know the domain-> they're visiting it.

IDEA -> use a form where people fill in their email adress to get your address. An automatically generated email could be sent to them. Another automatic email could be sent to you. That way you know who has your email address. This might be slightly user unfriendly but can be good for some situations.

IDEA -> Use a catch-all email address to receive email. Use the viewer's IP address for the email address that they are given on your website. i.e. This could be useful to keep track of who is emailing you. When the email is real, you give them your genuine address. When the email is spam, you have their IP. This is probably not completely spam-proof, but maybe there are other ways to use email addresses based on user-info, to track who is emailing you and get info about the spammer.

UNSPAM -> An initative of to forbid compliant robots from harvesting email addresses. Usage: <meta> Replace the [link to your terms] with a link to your terms of use page. Alternatively you may include a link to

I don't know how well the unspam idea really works, but I like it and it might scare off some parties.

Tony -  AQK’s photoTony - AQK replied on

Yeah, I've investigated most of these methods.

The Flash methods seems worthy, but much to my horror, I recently found one of my Flash embedded-text on Google! Google had actually disassembled the swf and put the legible stuff online. If they can do it, so can a malevolent spam-spider.

Temporary measure: One way, perhaps, is to put the email-id in pieces in a text file, and have the swf load it and re-assemble it at object-time. This is what I am developing now. ANYTHING to avoid capchas! ;-) But I'm sure eventually a nasty email-harvester would figure their way thru this. If they haven't already...

Thanx fer some great ideas.. too bad I already thought of most of them.. ;-)

Joe replied on

All the "spammers" have to do is read a few webpages like this one and come up with numerous ways with simple perl scripts to find real mailto tags or addresses with html comments or just plain text with @ changed to "at" or "[at]".

how can anyone trust some other site to not sell the email adresses?

php scripts etc seem complicated for casual bloggers etc...

I think an image with no mailto link is about the only way that seems reasonable from what I've read here.

Mike’s photoMike replied on

Something not mentioned here is that document.write() function of javascript does not work with XML or XHTML (served as application/xhtml+xml). There used to be a hosted cgi script that worked pretty good, but I don't remember what happened to the host (and the source was never disclosed for the obvious reasons).

That really is the best thing. Come up with your own solution and DO NOT tell anyone what it is! Then the likely hood of it being negated by spam bots is GREATLY reduced!

Michal replied on

Thanks for huge list of hints, however, I think those who are afraid readers of their pages are too lazy to read their address coded in form of an image and write it into mail client need to invest to a good spam filter and use a script-based "encryption" (if they can survive customers without script allowed will not read it).

For those who expect e-mails from people who consciously decided to write having a good reason for that, for those (including me) showing address in form of an image without "mailto:" ref is not a problem.

At the same time it is definitely problem for bots.

William White’s photoWilliam White replied on

I really like this study - it was extremely informative. I would have liked to see more data about email addresses in the form of images. I’ve just developed a new technique to have Apache webserver automatically convert all email addresses in HTML source into images in the output stream. It is all seemless and on-the-fly, and all without touching the source format in any way. I’ve written a proof-of-concept /w example on my blog.

Marc Arbour’s photoMarc Arbour replied on

Here is another tool to encrypt your email address.

It goes along EXACTLY what examples are being given here.

I like this website since it's a mere fill-copy-paste to my protected email address on my web page.



Patric’s photoPatric replied on

I think the best way is to output your email adress as usual, along with a few fake ones that is hidden from human visitors (i.e only visible in the source code). Add and and automatically flag any mail to any of these two adresses as fake. Then, when you are checking your email, the software needs to check these two accounts first to harvest spam, and then download emails from your real adress - excluding the ones that previously has been marked as spam.

The only problem might be to find this kind of software :D

David replied on

The question I ask myself is, why would spammers waste resources trying to decrypt even the most basic of these methods? The kind of people who would go to the small trouble of even the most basic methods are surely smart enough to not open any spam let alone buy something or pay anyone money.

Boris’s photoBoris replied on

Is there some solution for encrypting emails in flash? Some actionscript encrypter? Approach for flash movies mentioned in this article is quite inefficient! Google is able to grab any text data containing in swf incl emails. So don't be surprised about seeing your email adress on google... And spam bots use google to obtain email-adresses!! Please let me know if you know any solution for that problem.

Man And Cat’s photoMan And Cat replied on


I'm using my own template class which has a function to split the e-mail into smaller strings, then joins them back using HTML comments between them.

The dummy address would look like this:

<!-- >@. -->test.<!-- >@. -->address<!-- @. -->@<!--detolsaeimdmatesveerstsernres.>@. -->some.<!-- >@. -->email.<!-- >@. -->server.<!-- >@. -->net<!-- >@. -->
The more dots are in the address, the larger the text it is.

It also generates an anchor HTML element:

<a href="">onclick="window.location='ma'+'il'+'to:' + this.innerHTML.replace(/<!(?:--[\s\S]*?--\s*)?>\s*/g, ''); return false;">the obfuscated e-mail address</a>
The browser displays the address correctly, and the link works. I've tested it on IE7, FF2, Chrome and Netscape.

This also enables the user's email client. I wonder if the bots are smart enough to extract the ReX from the JavaScript replace function in order to get the correct email address.

Scopulus replied on

The only problem is that once your email is out there it's out there. Plus some directory's list your email address.

If you combine two or more of the suggestions in this article then you should minimise your email spreading further.

We have used &#38;#64; for @ and a redirect php.

I have checked and most of all the big firms do not try any of these methods. I think the reason is they want people to contact them and they are prepared to deal with the spam as all businesses have too deal with the problem at some level.

Either that or the alpha geek is over paid.

Chris’s photoChris replied on

Why not combine a couple? How about having an image that people can read as an email address, couple with a javascript that pieces together the email address?

vuduu’s photovuduu replied on

I found another cleverly way in website,

explode from "@" and "." for 3 or 4 piece.

replace "@" to "@picture"

replace texts with php "strrev" function

display replaced texts with css+xhtml unicode-bidi:bidi-override;direction:rtl;

also few times i see a null spans and images between exploded texts and image