Masking by character encoding

Common character encoding, used when masking email addresses in the source code, is based on HTML entities, HEX code, or the percentage of URL encodings. These descriptions were originally developed for representing special characters through standard characters. For masking email addresses, this type of encoding is suitable because the respective reference characters are automatically translated in the browser view. If the characters of the email address are masked using HTML entities, they are first written in the alternative style.

@ = @

. = . (dot)

This results in the following source code:

<p> If you have any questions or suggestions, please write an email to: 
  <a href="mailto:user&commat;domain&period;com"> user&commat;domain&period;com</a>

Since HTML entities have only been defined for special characters, this means that with this character encoding, neither the entire email address nor the significant text string mailto: can be encrypted. Alternatively, a representation using HEX encoding is possible. The Unicode character number is used here and is listed in the following basic schema:


On the visible web page:

“For more information, send email to”

In the source code for the web page, the above should look like this:

“For more information, send email to

<A HREF="mailto:
This online tool can be found here:

The corresponding reference characters for translating an email address can be easily found from lists available online. A clear overview is provided on If you want to encode the complete email address, we recommend encoding programs that are offered free of charge as web applications on numerous websites.

Another way to protect email addresses from spam is to use URL encoding. This method was originally developed to assign special characters in a URL to something that the browser could interpret. Three-character combinations are used that originate from the two-character ASCII hexadecimal code of the respective character and a pre-defined percentage symbol. The following example shows an @ sign being masked by URL coding:

<p>If you have any questions or suggestions, please write an
  <a href="">email</a>.

In principle, masking the email address can be quickly and easily done by character encoding. The protection is comparatively low presently since most spambots are now programmed to easily decipher this simple form of encryption.

Masking by supplementing

Basically, it is possible to hide email addresses from spambots by inserting additional characters into them. Programs will then hopefully not see the address as a whole and therefore it won’t be able to be read out automatically. HTML comments provide a simple way to do this.

<!– Comment –>

Ideally, these include just the characters that are normally used in email addresses.

<!– abc@def –>

<!– –>

If comments like these are added into the email address, spambots (who scan the website) will stumble across the following code:

<p>If you have any questions or suggestions, please write an email to:
us<!-- abc@def -->er@domai<!-- --> 

In the browser view, however, the HTML comments are invisible.

Alternatively, it is possible to insert any characters without comments, as long as they are hidden in the browser view using CSS. In the following example, the email address is interrupted by a span element. The content between the start and the end tag isn’t considered because of the display quality along with the value none.

<style type="text/css">
span.spamprotection {display:none;}

<p>If you have any questions or suggestions, please write an email to:
user<span class="spamprotection">CHARACTER SEQUENCE</span> 

While a human user receives a correct email address in the web browser, a spambot is expected to read out the blended text in the span element. This gives website operators the option to use the email address as a so-called honeypot in order to locate sender addresses and block them from spam attacks.

A disadvantage of masking by supplementing is that with this method the email address can’t be connected with an HTML email link. In this case, users must manually copy the address into their email program.

Reversing a string

CSS can be used not only to hide additional characters in the source code, but also to reverse the string. This enables website operators to store email addresses in the wrong order in the source code in order to deceive spambots.

<style type="text/css">
span.ltrText {unicode-bidi: bidi-override; direction: rtl}
<p>If you have any questions or suggestions, please write an email to:
<span class="ltrText"> moc.niamod@resu</span>.

While spambots find the character string moc.niamod@resu in the source code, the CSS property unicode-bidi ensures (along with the value bidi-override) that all characters within the appropriately distinguished span elements are read by the browser just as the quality direction intends them to be – in this case from right to left (rtl).

This masking means that email addresses aren’t displayed as they usually are. However, more advanced spambots can’t be deceived by this trick.

Dynamic composition with JavaScript

JavaScript offers another way to make sure the correct email address is displayed in the browser. The address is divided into several parts that are dynamically composed by the browser when the website is called up.

<script type="text/javascript">
var part1 = "user";
var part2 = Math.pow(2,6);
var part3 = String.fromCharCode(part2);
var part4 = ""
var part5 = part1 + String.fromCharCode(part2) + part4;
document.write("If you have any questions or suggestions, please write an email to:
   <href=" + "mai" + "lto" + ":" + part5 + ">" + part1 + part3 + part4 + "</a>.");

In lines 2 to 6, the individual sections of the email address are defined. The @ sign is defined in two steps. The Math.pow(2,6) function in part2 determines the number of the character in the ASCII compatible character sets (26 = 64). This is converted to the corresponding character in part3 by the function String.fromCharCode(part2). The output of the parts defined in part1 to part5 is performed in lines 7 and 8 by the document.write() function. The email address becomes available only after client-side execution of the script. It’s also possible to have a variant where the script is only started once the user has clicked.

Anti-spam methods that use scripts for dynamic composition are based on the assumption that email harvesters can’t fully implement JavaScript. If this is the case, it could be assumed that there’s a high level of protection. The disadvantage of this method is that users who have deactivated JavaScript in their browser aren’t displayed as much contact information as they should be. This doesn’t affect many users today though.

Professional Email Address & Personal Domain Name

Get an email address as professional and unique as you are including a free matching domain!

Encrypting the email address

With JavaScript, email addresses can not only be assembled from individual parts, but the scripting language also enables you to encrypt the email address to protect it from spam. A common method for email encryption is ROT13, which can be implemented with just a few lines of JavaScript.

<script type="text/javascript">
function decode(a) {
  return a.replace(/[a-zA-Z]/g, function(c){
    return String.fromCharCode((c <= "Z" ? 90 : 122) >= (c = c.charCodeAt(0) + 13) 
                               ? c : c - 26);
function openMailer(element) {
var y = decode("znvygb:orahgmre@qbznva.qr");
element.setAttribute("href", y);
element.setAttribute("onclick", "");
element.firstChild.nodeValue = "Open email software";
<a id="email" href=" " onclick='openMailer(this);'>Email: please click</a>

In line 9 of the sample code, it shows the encrypted version of the email address including the mailto text string (znvygb:orahgmre@qbznva.qr) as well as how it should be encrypted (in lines 2 to 7). The function in lines 8 to 13 opens the user’s preferred email program and writes the decrypted address into the recipient field.

The script is started by clicking on the link with the anchor text ‘Email: please click’ (lines 15 to 16). After being clicked on, this displays the text ‘Open email software’ (line 12).

Just like the JavaScript-based composition of the email address, the encryption method is based on the assumption that spambots can’t interpret the entire client-side script language or can only partly interpret it. Theoretically, the encrypted email address could be used as a honeypot. In this case the domain should not be encrypted.