Stopping Spam Bots from Harvesting Your Email

Publishing a plain mailto: link on a website is the digital equivalent of posting your address on a public billboard—it’s convenient, but it invites every scraper and spam bot on the internet to flood your inbox. The goal is to find a middle ground: make it difficult for automated crawlers to extract your address while keeping it trivially easy for human visitors to read and use.

The common thread across every viable technique is obfuscation—disguising the email address so that pattern-matching bots fail to recognize it, while the browser renders it correctly for users. Below are four practical approaches, each with trade-offs in complexity, accessibility, and functionality.

The HTML Comment Trick

Bots scan HTML documents for strings that match the standard email format. One of the simplest ways to break that pattern is to insert HTML comments directly inside the address, splitting it into fragments that a naive parser won’t reassemble:

<a href="mailto:[email protected]">Send me an Email</a>

When rendered in a browser, the comments are ignored and the user sees the complete address:

<p>If you want to get in touch, please drop me an email at<!-- fhetydagzzzgjds --> email@<!-- sdfjsdhfkjypcs -->addr<!-- asjoxp -->ess.com</p>
  • Pros: Works without JavaScript; readable by assistive technology; trivial to implement.
  • Cons: Modern spam bots can strip known comment sequences; does not work inside a mailto: link.

The HTML + CSS Masking Approach

CSS can also be used to hide a decoy portion of the address from users while leaving it in the DOM for bots to find. Here, a span element contains extra characters, and CSS hides that span:

If you want to get in touch, please drop me an email at [email protected]

With the following style rule applied, the fake segment disappears from view:

<p>If you want to get in touch, please drop me an email at <span class="blockspam" aria-hidden="true">PLEASE GO AWAY!</span> email@<!-- sdfjsdhfkjypcs -->address.com</p>.
  • Pros: Slightly more resistant to bots than comments; functions without JavaScript; accessible via assistive tech.
  • Cons: Still no support for mailto: links; a determined scraper can execute or parse CSS to reveal the full string.

Decoding with JavaScript

For a more robust defense, you can store the email address in an encoded form in the markup, then decode it client-side once the page loads. The simplest method is Base64 encoding. First, encode your address—services like Base64Encode.org can do this for you—and then use JavaScript’s atob() method to decode it and assign the result to the link’s href attribute:

span.blockspam {
  display: none;
}

Your anchor tag only needs an identifier to signal the script:

If you want to get in touch, please drop me an email at [email protected].

If you want even stronger protection, substitute a simple encryption algorithm like the Caesar cipher; implementing it in JavaScript is not complicated.

  • Pros: Substantially harder for bots to crack; supports mailto: links; readable by assistive technology.
  • Cons: Fails completely if JavaScript is disabled—the link renders empty.

A fundamentally different approach is to remove the email address from public view altogether. Instead, embed a contact form powered by a third-party service like Formspree or Wufoo. These services handle the server-side processing, routing submissions to your inbox while keeping your address private. Here is an example snippet from a form created through Formspree:

A large textarea to paste an email address with a series of options beneath it for how to encode the text.

Notice the hidden input field included in the form markup. Formspree’s backend automatically discards any submission where that field is populated—a clear signal that the submission was made by an automated bot rather than a human. Pricing and features vary by provider, but most offer embeddable HTML snippets that you can add to any page with minimal customization, starting with your personal action endpoint.

  • Pros: Your actual email address is never exposed; works without JavaScript.
  • Cons: Relies entirely on a third-party service for delivery.

This last method carries another caveat that is more about user expectations than technical limitations: it removes direct email contact entirely. Some visitors specifically want to write to an email address, not fill out a form. For those situations, a contact form is a heavier-handed solution than the situation calls for.

Each of these strategies has a different balance of security, compatibility, and user experience. The right choice depends on your needs—whether you prioritize serving users without JavaScript, keeping a native mailto: interaction, or keeping your address off the public web completely.