Email obfuscation: What works in 2026?

I stopped being concerned about email harvesting years ago, I just simply leave the email on my website. Spam handling is okay enough, I guess.

But I like this review of techniques, even the simplest ones are very effective, that surprised me.

It's odd. My email address is included un-obfuscated in ~90 commits to a popular open source repo on github. I also use this same email address for a mailing list associated with this OSS project. As far as I can tell, I've never received a single spam email in the 8 years I've had this email account.

When I view a commit on the github UI using view source, I can see the commit author's email address just as text with no special handling. It's bracketed by "<" and ">", so maybe that's enough to confuse harvesters.

I just looked at the spam folder of one my personal accounts (where I sign up for services), and it has got tons of stuff, most recently 2 or 3 with the subject "YOU PERVERT! I RECORDED YOU!".

It seems spammers are doing less harvesting and more purchasing of email lists from service vendors.

I have a hypothesis email scrapers don't parse HTML at all. I suspect they search the raw bytestring for @ characters and take whatever's on either side of it. That probably gets them as many addresses as they can realistically use at a fraction of the cost, given how expensive HTML parsing can be.

(Similarly, I'm sure most links can be found by searching the bytestring for "href" and taking what's to the right of it.)

This would explain why HTML entities are so effective.

On the other hand, surely the TLS handshake is far more expensive than HTML parsing? Maybe it's to avoid parser failure modes that consume a lot of resources?

Really surprised this [very well-written] article didn't suggest the fantastic technique of owning an entire domain (although author's own examples obviously include unique handles@ for each tested practice).

Then you can hand each recipient an absolutely unique email which isn't just ole "name.morewords@" period trick — block those which receive SPAM.

----

OR: the even "easier" lifestyle of just not using email (like me). Obviously this is difficult for modern living, but that's what temp email is best for [i.e. circumventing ubiquitous `REQUIRED` email address fields].

I recently noticed an uptick in cold emails and spam after publishing my new website. After a few weeks, I asked Claude/Cursor to obfuscate the email for spam protection in the mailto: link, and thy both used JavaScript with data attributes.

Something like:

``` <a href="#" class="js-mailto ${className}" data-email-user="${local}" data-email-host="${host}" data-email-subject="${sub}" > ${children} </a> ```

And then some light vanilla JS to stitch it together. Works in the browser, and spam has dropped off a cliff since.

One trick is having an tarpit email adress on your website. It is hidden using CSS so no real visitor sees it but it is visible in source. If your mail server recieves mail for that adress you can just block that IP for 24h.

Good stuff, but I think the title should be Email address obfuscation. Thank you for sharing I guess, but spammers can now learn from this too (:

Some time ago i was wondering if the common "me at foobar dot com" you still see a lot of people do actually helps at all, especially now with LLMs, so i searched for some common "obfuscation" techniques and found this site (not the 2026 update, but the previous - it was a few months ago). Then i wrote a simple LLM query with a bunch of examples from the site[0] (the tool is just a frontend for a commandline program that uses llama.cpp and Mistral Small 3.1 in Q4_K_M quantization since it loads relatively fast and is fine for simple prompts). AFAICT it could reveal anything that wasn't relying on CSS tricks or JavaScript.

Like others mentioned, though, personally i haven't bothered by email harvesting for years now since spam filters seem to do a decent job. I have my email posted in plaintext here (which i bet is harvested very often) and in various other places and the occasional spam i get is eclipsed from "spam" from services i've actually signed up for (coughlinkedincough).

[0] https://i.imgur.com/ytYkyQW.png

interesting that most scrapers are still just regex-searching for @ in raw bytes. on the receiving side i've been dealing with a different angle of the same problem, blocking disposable/temp email signups. a domain blocklist catches 90% but the clever ones use random alias domains that all point their MX records to the same disposable mail infrastructure. checking where MX records actually resolve catches those too

When I wrote my own brainf*ck interpreter (in C) at the start of the year I was really struggling to find a use for the language. Eventually I had the idea to obfuscate emails on my websites with the language.

Basically each email gets written as a brainf*ck program and stored in a "data-" attribute. The html only includes a more primitively obfuscated statement "Must enable Javascript to see e-mail." by default which then gets replaced by another brainf*ck interpreter (in JS) with the output of the brainf*ck code. Since we only output ASCII we can reduce the size of the brainf*ck code by always adding 32 to each value it outputs. The Javascript is loaded from what seemingly looks like a 3rd party domain. There we filter basing on heuristics and check if the "referer" matches before sending out the actual interpreter code.

Of course all this would not help if a scraper properly runs things through Javascript too.

Recently I read you soon will be able to run DOOM via CSS, so certainly it should be possible to have a brainf*ck interpreter in CSS? That would be the next step… just to get rid of the Javascript, but then I'm okay with all the downsides of using Javascript just for the e-mail obfuscation.

Anyway… I also regularly (at least once a year) rotate those public contact addresses.

This is a great list on how to make an email harvester even better.

They left off html cgi form. Generate the email on the web page and the server sends the email after performing some basic sanity checks and anti-spam on the form and web server itself such as solving some CSS puzzle or winning a game of DOOM.

It's simple: draw your email in a paint program and export it as a png. Totally readable by humans.

Very interesting. It seems for his own email the author has opted for a combination of the CSS display none technique and a XOR cipher:

  <span class="hidden email"><b>999a8f84898f98</b>aa<b>878b8386c4</b>999a8f84898f988785989e8f84998f84c4898587</span>

WTH, a 302 into a "mailto:" (search for "HTTP redirect" in the featured article) opens up my e-mail client without clicking a mailto link!? This seems wrong.

I use a very simple encryption plus some padding (fluff in the article), but the email address gets updated by JS. This requires JS plus evaluating the resulting DOM. If you don't evaluate JS, the address will be something like "please@activate.javascript". Or you could use "potus@whitehouse.gov", in which case clueless scrapers end up spamming the US government.

> HTML entities are often decoded automatically by server-side libraries, which means that even the most basic harvesters can get your email addresses without any special effort. This technique should be worthless—and, yet, it still stops most harvesters.

Anecdotal, but I’ve used HTML entities on a public static website for a long time using an href tag with mailto, and yet I’ve not seen any spam.

I guess any spammer who uses some level of GenAI to process and extract email addresses would have a lot more success against all the methods listed in this article.

GitHub has a spot to display your email on your profile; is this obfuscated as well? Most of my current spam is from putting my email on there..

What I often see is js that fetches the email from the server separately and inserts it.

What I do is I have a catch all, and based on the emails I get, I know which emails are made public, and I scout what the threat actors are doing.

For a similar reason I dislike ip2ban, my objective is not to block all attack attempts, I prefer receiving them acknowledging them and being immune to them.

The idea of ignoring attack attempts isn't very safe when you think about it, your body doesn't do that, it creates antibodies upon subclinical expositions. Complete isolation means your immune system is weak and you are more vulnerable to the lightest of exposures.

I'm surprised that html entity supstitution performs so well. I would have assumed that scrappers could at least speak proper html.

I use SVG where I created a text object in Affinity Designer and converted it to curves so the SVG doesn't have text any more, just vectors for the glyphs of it. Seems to work pretty well at keeping spammers at bay.

I've never obfuscated my mail and do not use server-side spam filters, yet have never had a problem with spam. Yes, I get maybe twice or three times as much spam than legitimate mail (if we include spam that was once (semi-)authorized when clicking the wrong option). However, it's all filtered reliably client-side.

I filter everything that does NOT include “+asdf” in the to:

I'm sorry, but that is not how email address are spammed in bulk.

The data-source are the enormous data breach that are more and more frequent. There is more intensive to collect more information on someone you already know something about than spamming an email you don't even know if it's a valid one.

The spam can also be very more effective as it present itself with personal information about the spammed.

This is such a waste of effort. Your E-mail address is not and can't be a secret. It will get into spammer databases eventually, no matter what you do. You will spend a lot of effort doing all these fancy tricks, and eventually you will get spam anyway.

Also, a note to those who make fancy "me+someservice@somedomain.com" addresses: make really sure you are in control and these work. Some services (including mine) will need to E-mail you one day, for example to tell you that your account will be deleted because of inactivity. If you don't receive that E-mail because of your fancy spam defenses, your account will be deleted. I've seen people hurt themselves like this and it makes me sad.

On a constructive note: what works very well is spam filtering using LLMs. We have AI to help us with this problem today. I wrote an LLM despammer tool which processes my inbox via IMAP using a local LLM (for privacy reasons). I see >97% accuracy in my benchmarks on my (very difficult) testing corpus. It's nearly perfect in real life usage. I've tested many local models in the 4-32B range and the top practical choice is gpt-oss:20b (GGUF, I run it from LM Studio, MLX quantizations are worse) — not only does it perform very well, but it's also really fast.

I stopped being concerned about email harvesting years ago, I just simply leave the email on my website. Spam handling is okay enough, I guess.

But I like this review of techniques, even the simplest ones are very effective, that surprised me.

Very interesting. It seems for his own email the author has opted for a combination of the CSS display none technique and a XOR cipher:

  <span class="hidden email"><b>999a8f84898f98</b>aa<b>878b8386c4</b>999a8f84898f988785989e8f84998f84c4898587</span>

I filter everything that does NOT include “+asdf” in the to:

Good stuff, but I think the title should be Email address obfuscation. Thank you for sharing I guess, but spammers can now learn from this too (:

https://www.gregegan.net/

Contact details: [any mailbox] [at] [the domain name of this web site]. Please don’t ask me to give interviews, sign books, appear on podcasts, attend conferences or conventions, or provide feedback or endorsements for works of fiction, scientific theories, or slabs of text disgorged by chatbots.

I have no idea how to decipher this obfuscation.

Anecdotal, but I’ve used HTML entities on a public static website for a long time using an href tag with mailto, and yet I’ve not seen any spam.

I guess any spammer who uses some level of GenAI to process and extract email addresses would have a lot more success against all the methods listed in this article.

I wouldn't think it's very cost effective to apply GenAI to extract email addresses

It also keeps visually impaired people at bay.

I'm sorry, but that is not how email address are spammed in bulk.

The spam can also be very more effective as it present itself with personal information about the spammed.

The OP put those addresses on that web page, and only on that web page. Some addresses received spam.

Edit: that’s not to deny that big data leaks are a serious problem

I wouldn't think it's very cost effective to apply GenAI to extract email addresses

It also keeps visually impaired people at bay.

The OP put those addresses on that web page, and only on that web page. Some addresses received spam.

Edit: that’s not to deny that big data leaks are a serious problem

> Also, a note to those who make fancy "me+someservice@somedomain.com" addresses:

Just wait until one of these companies demands an email from the registered email address of your account!

Plus-addressing is built in to most email services. There's no 'fancy' set up to break; it just works. That is, there's no way me@gmail.com works but me+someservice@gmail.com doesn't, unless you explicitly configure it not to work. Similarly for custom domains on most services.

If you use a catch-all on a domain, i.e. someservice@somedomain.com, I guess in theory that might break. But it seems about as likely as messing up the overall domain setup.

Also, my account on your service is likely much more disposable to me than my email address/domain. Anything I care about, I'd back up. Not just assume some random website is going to preserve it for me forever.

The techniques in the article right now have had around 95%-100% success at avoiding spam and take about 5 min. to implement. Your approach of putting an LLM in front of your inbox gives 97% accuracy, may have false positives (so you may not receive that account deletion email after all), requires to run inference and, I assume, would take at least an hour to setup.

Also, the two can be complementary, anyways, so I am not sure what your point is.

https://www.gregegan.net/

I have no idea how to decipher this obfuscation.

What's difficult about it? You know the domain, gregegan.net. You know the @ symbol, presumably. Then put literally any valid text before the @.

> Also, a note to those who make fancy "me+someservice@somedomain.com" addresses:

Just wait until one of these companies demands an email from the registered email address of your account!

Also, the two can be complementary, anyways, so I am not sure what your point is.

If you use a catch-all on a domain, i.e. someservice@somedomain.com, I guess in theory that might break. But it seems about as likely as messing up the overall domain setup.

What's difficult about it? You know the domain, gregegan.net. You know the @ symbol, presumably. Then put literally any valid text before the @.

Completely unrelated to the conversation, but our user names are remarkably similar.

I just looked at the spam folder of one my personal accounts (where I sign up for services), and it has got tons of stuff, most recently 2 or 3 with the subject "YOU PERVERT! I RECORDED YOU!".

It seems spammers are doing less harvesting and more purchasing of email lists from service vendors.

I have a wildcard address at my domain. The most common email addresses for spam are:

- git@mydomain.com

Presumably harvested from GitHub or gitlab

- contact@mydomain.com / admin@mydomain.com

Not actually an email address ever used, presumably people just guessing these exist from convention.

- <first name>@mydomain.com

I mean, if you know my name you can probably guess this but also this has been my primary email address for outbound email and so has ended up in marketing lists etc.

- ap@mydomain.com, finance@mydomain.com

This is a very recent trend but I've been getting emails to made up addresses like these ones quoting forged emails from myself (with various titles like CEO or CFO attached) claiming to authorize payments to other parties, usually backdated, and then asking that I process their invoice ASAP because look how long ago the CEO said it should be paid. I guess my website has ended up in some list of businesses despite being a personal site.

Ironically, the address that was in plain text in my HN profile for like 15 years gets very minimal spam.

Completely unrelated to the conversation, but our user names are remarkably similar.

This sounds like bad advice and would result in blocking google and other major ESPs.

I occasionally get spam from people who took the time to create gmail accounts. Based on this advice, the honey pot email address would get spam from a Gmail account and your script would block Gmail servers.

Similar in spirit to this: https://www.projecthoneypot.org/

Then you can hand each recipient an absolutely unique email which isn't just ole "name.morewords@" period trick — block those which receive SPAM.

----

(Similarly, I'm sure most links can be found by searching the bytestring for "href" and taking what's to the right of it.)

This would explain why HTML entities are so effective.

On the other hand, surely the TLS handshake is far more expensive than HTML parsing? Maybe it's to avoid parser failure modes that consume a lot of resources?

[0] https://i.imgur.com/ytYkyQW.png

Something like:

``` <a href="#" class="js-mailto ${className}" data-email-user="${local}" data-email-host="${host}" data-email-subject="${sub}" > ${children} </a> ```

And then some light vanilla JS to stitch it together. Works in the browser, and spam has dropped off a cliff since.

What I often see is js that fetches the email from the server separately and inserts it.

I'm surprised that html entity supstitution performs so well. I would have assumed that scrappers could at least speak proper html.

What I do is I have a catch all, and based on the emails I get, I know which emails are made public, and I scout what the threat actors are doing.

For a similar reason I dislike ip2ban, my objective is not to block all attack attempts, I prefer receiving them acknowledging them and being immune to them.

Years ago, I considered your approach. Programmatically create a custom email address for each person I wanted to talk to.

Then I hit upon a simpler solution. Have one email address. Happily share publicly. And whitelist the sender's email addresses. Emails not in the whitelist go into a quarantine folder that I glance at once in a while.

It's almost equivalent in efficacy, but much simpler to implement.

I've been doing that for two decades. Most of the spam comes directly to my primary gmail. Because I shared that with friends and family. And at least some of my friends and family shared their entire contact list with the wrong app at least once.

This article however is talking about publishing your email address on a public website. It matches my experience, that simple javascript concatenation stops 100% of spam. Not that I would or ever did trust my primary email address to that.

> This would explain why HTML entities are so effective.

Could also be that they learned that sending spam to obfuscated addresses doesn’t gets much response. Such messages might get filtered out more and/or addressees might be less inclined to reply to it.

I believe you’re right. But sometimes, you really have to think about how mad your adversary is.

A dog will keep biting long after that is a disastrous plan.

it really varies, you are correct most modern ones search the byte string for @ characters but there are probably hundreds of different methods out there in black hat marketing circles to scrape emails.

Token based extraction around the @ is definitely one way that can work with a few tweaks.

IMO a better approach would be individualized addresses.

Imagine someone visiting your blog who wants to e-mail you can burn some CPU cycles to "earn" an address that hasn't been given out to anybody else, e.g. user+TOKEN@example.com, where it is algorithmically-unlikely for them to be able to guess a different TOKEN that will work. Then if abuse occurs, you can just retire that one address. (In a non-interactive context, like a paper ad, you could just generate one yourself.)

Naturally, this would be best with an e-mail client that is aware of the scheme, and with a mail-service that has some API for generating new addresses, such as if you want to cold e-mail somebody and use a new from/return address.

Some years ago I had the fanciful idea of doing it with a phone-app, where it manages creating new addresses as-needed, disabling them, and keeping notes about who you gave them to.

I would expect that a llm based scraper is going to be better at parsing an email address from your instructions than some of the more inattentive people who's emails you might want to receive. So I think some of the dumber mitigation measures that still block the simple regex bots from this topic are probably a better bet now.

Relevant xkcd: https://xkcd.com/1808/

It's simple: draw your email in a paint program and export it as a png. Totally readable by humans.

Then I can't copy+paste, so I might make a typo when sending you a message.

...humans with vision in good working order. There's a large subset of humans who would then have no way of contacting you.

GitHub has a spot to display your email on your profile; is this obfuscated as well? Most of my current spam is from putting my email on there..

Your email is still available from the actual commits presumably.

This is a great list on how to make an email harvester even better.

Yes and no, some techniques are still expensive for bots that aim to extract millions of addresses per day (like running JS and CSS, rendering SVG, etc).

Of course all this would not help if a scraper properly runs things through Javascript too.

Anyway… I also regularly (at least once a year) rotate those public contact addresses.

How does this approach meaningfully differ from having javascript that XORs the email with a random sequence of bytes stored in that JS?

How does that work if the scraper takes a screenshot to feed to a LLM or OCR?

WTH, a 302 into a "mailto:" (search for "HTTP redirect" in the featured article) opens up my e-mail client without clicking a mailto link!? This seems wrong.

Some browsers ask whether to open the email client in that case. I don’t see it as significantly different from a redirected download link that would open a program based on the mime type or file ending. Or from a redirect to another URL pattern associated with an app, like for example how YouTube links may open in the YouTube app.

Similar in spirit to this: https://www.projecthoneypot.org/

I have a wildcard address at my domain. The most common email addresses for spam are:

- git@mydomain.com

Presumably harvested from GitHub or gitlab

- contact@mydomain.com / admin@mydomain.com

Not actually an email address ever used, presumably people just guessing these exist from convention.

- <first name>@mydomain.com

I mean, if you know my name you can probably guess this but also this has been my primary email address for outbound email and so has ended up in marketing lists etc.

- ap@mydomain.com, finance@mydomain.com

Ironically, the address that was in plain text in my HN profile for like 15 years gets very minimal spam.

This sounds like bad advice and would result in blocking google and other major ESPs.

There exist lists of email providers. Those you can whitelist, ie. they can't get on the blacklist. Even then they would only be blocked temporarily. There also exists postmaster@domain.com which should not filter at all. I am aware that you are able to abuse said system but if you monitor logs those issues would only be temporary.

Yeah, I mean, you can personally vet those domains/IPs?

> This would explain why HTML entities are so effective.

Years ago, I considered your approach. Programmatically create a custom email address for each person I wanted to talk to.

It's almost equivalent in efficacy, but much simpler to implement.

This is your configuration error (likely just using a simple catch-all)?

When configured correctly each family member can reach you at a custom handle@, even seeing this custom reply address in response emails from you.

----

But yes, you're correct about the purpose of OP's article (website obfuscation). The topic-overlap is so close that it's still worth mentioning, IMHO.

I believe you’re right. But sometimes, you really have to think about how mad your adversary is.

A dog will keep biting long after that is a disastrous plan.

Token based extraction around the @ is definitely one way that can work with a few tweaks.

IMO a better approach would be individualized addresses.

Some years ago I had the fanciful idea of doing it with a phone-app, where it manages creating new addresses as-needed, disabling them, and keeping notes about who you gave them to.

Sounds like a similar approach to this service: https://addy.io/

I use it all the time in conjunction with Bitwarden to generate unique emails per site. You can have notes in each email, and they show up in a small banner on in the forwarded email. And each one is individually disable-able, so you can easily cut it off if you see spam from it.

I was really interested in this space and made my own homegrown tool for this. I used it for a while until I discovered Addy and switched over. IIRC there are similar services by Mozilla, Apple, and Proton.

Relevant xkcd: https://xkcd.com/1808/

Haven’t heard “black hat marketing” before but that’s very fitting for a lot of the “growth hackers” out there

Then I can't copy+paste, so I might make a typo when sending you a message.

Your email is still available from the actual commits presumably.

...humans with vision in good working order. There's a large subset of humans who would then have no way of contacting you.

Yes and no, some techniques are still expensive for bots that aim to extract millions of addresses per day (like running JS and CSS, rendering SVG, etc).

Yeah, I mean, you can personally vet those domains/IPs?

This is your configuration error (likely just using a simple catch-all)?

When configured correctly each family member can reach you at a custom handle@, even seeing this custom reply address in response emails from you.

----

But yes, you're correct about the purpose of OP's article (website obfuscation). The topic-overlap is so close that it's still worth mentioning, IMHO.

How does that work if the scraper takes a screenshot to feed to a LLM or OCR?

That seems like a very expensive way to crawl the internet

How does this approach meaningfully differ from having javascript that XORs the email with a random sequence of bytes stored in that JS?

It's more fun? :)

/edit

And you can combine both approaches: XOR'ing the code first for good measurements. :)

Sounds like a similar approach to this service: https://addy.io/

It's more fun? :)

/edit

And you can combine both approaches: XOR'ing the code first for good measurements. :)

That seems like a very expensive way to crawl the internet

Scrape normally collect emails, if no email seen take screenshot and OCR OCR is cheap and REGEX is cheap

Haven’t heard “black hat marketing” before but that’s very fitting for a lot of the “growth hackers” out there

Scrape normally collect emails, if no email seen take screenshot and OCR OCR is cheap and REGEX is cheap

Last updated:

January 30, 2026

Here are some of the best techniques for keeping email addresses hidden from spammers—along with the statistics on how likely they are to be broken.

1 Plain text
- 1.1 No protection: blocked 0%
- 1.2 HTML Entities: blocked 95%
- 1.3 HTML Comments: blocked 98%
- 1.4 HTML SVG: blocked 100%
- 1.5 CSS Display none: blocked 100%
- 1.6 JS Concatenation: blocked 100%
- 1.7 JS Rot18: blocked 100%
- 1.8 JS Conversion: blocked 100%
- 1.9 JS AES encryption: blocked 100%
- 1.10 JS User interaction: blocked 100%
- 1.11 HTML Symbol substition: breaks usability
- 1.12 HTML Instructions: breaks usability
- 1.13 HTML Image: breaks usability
- 1.14 CSS Content: breaks usability
- 1.15 CSS Text direction: breaks usability
2 Clickable link
- 2.1 No protection: blocked 0%
- 2.2 HTML HTML entities: blocked 100%
- 2.3 HTML URL encoding: blocked 96%
- 2.4 HTML HTTP redirect: blocked 100%
- 2.5 HTML SVG: blocked 100%
- 2.6 JS Concatenation: blocked 100%
- 2.7 JS Rot18: blocked 100%
- 2.8 JS Conversion: blocked 100%
- 2.9 JS AES encryption: blocked 100%
- 2.10 JS User interaction: blocked 100%
3 Observations
4 Methodology

1 Plain text

These techniques protect an email address written out in plain text (e.g. “email@example.com”).

Ideally, you should be using multiple techniques in combination, by splitting the email address into segments, where each segment is protected by a different technique.

1.1 No protection

Blocked 0% of 318 spammers

HTML

aa@email.spencermortensen.com

Browser

aa@email.spencermortensen.com

1.2 HTML Entities

Blocked 95% of 318 spammers

HTML

ab@email.spencermortensen.com

Browser

ab@email.spencermortensen.com

HTML entities are often decoded automatically by server-side libraries, which means that even the most basic harvesters can get your email addresses without any special effort. This technique should be worthless—and, yet, it still stops most harvesters.

Blocked 98% of 318 spammers

HTML

ac@email.spencermortensen.com

Browser

ac@email.spencermortensen.com

This will stop only the most basic harvesters that struggle with HTML tags. It offers minimal protection—and, yet, still manages to stop most harvesters (since most harvesters are basic).

1.4 HTML SVG

Blocked 100% of 318 spammers

HTML

<object class="email" width="130" height="24" data="email.svg" type="image/svg+xml"></object>

SVG: email.svg

<svg viewBox="0 0 130 24" xmlns="http://www.w3.org/2000/svg"> <style> @import url('https://fonts.googleapis.com/css2?family=Indie+Flower&display=swap'); text { dominant-baseline: middle; fill: #000; font-family: 'Indie Flower'; font-size: 16px; text-anchor: middle; } </style> <text x="50%" y="50%">email@example.com</text> </svg>

CSS

object.email { height: 2em; margin: -1em 0; vertical-align: middle; }

Browser

Inspiration: rouninmedia.github.io

This hides the email address in an unusual place where most harvesters won’t think to look. However, the email address is stored there in plain text.

This technique is accessible to all users, including those who depend on a screen reader. But you must use an object element for this to work: an img element would give you an image that is non-interactive, and inline SVG would put the email address in the source code where harvesters would find it easily.

The “width” and the “height” attributes help prevent layout shifts while the page is loading. Because the dimensions depend on the font, the SVG file has to explicitly specify a web font to prevent rendering issues.

1.5 CSS Display none

Blocked 100% of 318 spammers

HTML

<div class="email">ad@<span>email.</span>spencermortensen.<span>example.</span>com</div>

CSS

div.email > span:nth-child(2) { display: none; }

Browser

ad@email.spencermortensen.example.com

Most harvesters are unable to apply style rules, so this is one of the absolute best techniques. Be sure to vary the decoy tags so the harvester won’t know which parts to omit.

This is fully accessible to everyone, including those who depend on a screen reader. But you must use “display: none” to hide the text: if you use any visual-only technique (such as shrinking the font size, or repositioning the text off screen), then you’ll break accessibility.

1.6 JS Concatenation

Blocked 100% of 318 spammers

HTML

<script>document.write('a'+'i'+'@'+'e'+'m'+'a'+'i'+'l'+'.'+'s'+'p'+'e'+'n'+'c'+'e'+'r'+'m'+'o'+'r'+'t'+'e'+'n'+'s'+'e'+'n'+'.'+'c'+'o'+'m');</script>

Browser

This is convenient because it has no external dependencies, and yet still manages to block most harvesters. However, the full email address appears directly in the HTML source code, so this technique cannot be considered safe.

1.7 JS Rot18

Blocked 100% of 318 spammers

HTML

<span class="email">nw@rznvy.fcraprezbegrafra.pbz</span>

HTML

<head> <script src="[text-rot18.js](https://spencermortensen.com/articles/email-obfuscation/files/text-rot18.js)" defer></script> </head>

Browser

nw@rznvy.fcraprezbegrafra.pbz

This technique can be undone by basic harvesters that don’t interpret JavaScript. At the very least, you should rotate your letters by something other than 13, and rotate your numbers by something other than 5.

1.8 JS Conversion

Blocked 100% of 318 spammers

HTML

<span id="text-conversion">zibby example com</span>

HTML

<head> <script src="[text-conversion.js](https://spencermortensen.com/articles/email-obfuscation/files/text-conversion.js)" defer></script> </head>

Browser

zibby example com

In this technique, the HTML source code contains gibberish, and you write a custom function that converts the gibberish into a working email address.

Most harvesters can only access the HTML source code—and the source code contains nothing of value. The only practical way to restore the email address is to run your custom conversion function in a web client with DOM and JavaScript support. This is not possible for most harvesters.

You can write a custom function for each email address, or you can write a single function and apply it to all of the email addresses on the page.

Despite being frighteningly simple, this is expected to be one of the very best techniques.

1.9 JS AES encryption

Blocked 100% of 318 spammers

HTML

<span class="email">Kreuz2xa6xB8Fpjaa0lFgACNLO6n_Auu1CGjcG8z_Ec</span>

HTML

<head> <script src="[text-aes.js](https://spencermortensen.com/articles/email-obfuscation/files/text-aes.js)" defer></script> </head>

Browser

Kreuz2xa6xB8Fpjaa0lFgACNLO6n_Auu1CGjcG8z_Ec

This technique uses AES 256 to encrypt the email address. (AES is the only publicly-available cipher approved by the NSA for top secret information.) The email address cannot be recovered without the JavaScript file—which most harvesters cannot access or run. This implementation uses the browser’s own built-in cryptography library, so it will not run outside of the browser, even in JavaScript-capable environments.

The cryptography library, SubtleCrypto, is only available in secure contexts (such as over https or on localhost)—which could be a blocker if you’re using http. You must upgrade to https before you can use this technique!

1.10 JS User interaction

Blocked 100% of 318 spammers

HTML

<span id="text-interaction">whose baby example com</span>

HTML

<head> <script src="[text-interaction.js](https://spencermortensen.com/articles/email-obfuscation/files/text-interaction.js)" defer></script> </head>

Browser

whose baby example com

This technique keeps the email address hidden until the user interacts with the page; only then is the email address revealed. This raises the bar for harvesters: they not only need to run a full web client, they also need to interact with it.

This technique can be used to trigger other techniques.

1.11 HTML Symbol substitution

Blocked 97% of 318 spammers

HTML

ag AT email DOT spencermortensen DOT com

Browser

ag AT email DOT spencermortensen DOT com

This technique is well known, and easily reversible, so it cannot be considered safe.

Breaks usability. This forces the user to undo every substitution before they can send their email.

1.12 HTML Instructions

Blocked 100% of 318 spammers

HTML

au.fluff@email.spencermortensen.com (remove the “.fluff” before writing to me)

Browser

au.fluff@email.spencermortensen.com
(remove the “.fluff” before writing to me)

In general, only a human or an AI can break this. It’s mainly useful for when you need to publish your email address on an untrusted site.

This is at minimum inconvenient for your users, and may prevent them from reaching you at all.

Breaks usability. The user has to understand and follow the instructions perfectly, or they will be unable to reach you.

1.13 HTML Image

Blocked 100% of 318 spammers

HTML

<img src="[email.jpg](https://spencermortensen.com/articles/email-obfuscation/images/text-image.jpg)" width="216" height="18" alt="email address">

Browser

This is inconvenient or inaccessible for every one of your users.

Breaks usability. Sighted users are forced to type out the full email address by hand. The remaining users have no way to reach you.

1.14 CSS Content

Blocked 100% of 318 spammers

HTML

<span class="email" data-user="af" data-domain="email.spencermortensen.com"></span>

CSS

span.email::after { content: attr(data-user) '@' attr(data-domain); }

Browser

This breaks basic usability (e.g. the text can be seen, but not copied), so it is worthless.

It is possible for harvesters to recover the full email address from the HTML alone, without interpreting the CSS, so this cannot be considered safe.

Breaks usability. The email address can be seen, but not selected. This is very frustrating! Eventually, the user is forced to give up or type out the full email address by hand.

1.15 CSS Text direction

Blocked 100% of 318 spammers

HTML

<span class="email">moc.nesnetromrecneps.liame@ea</span>

CSS

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

Browser

moc.nesnetromrecneps.liame@ea

This technique breaks usability, and can be undone by basic harvesters that don’t interpret CSS, so it is useless.

Breaks usability. The email address can be copied, but the text is reversed. Eventually, the user is forced to give up or type out the full email address by hand.

2 Clickable link

These techniques protect a clickable link that will open the user’s mail client (e.g. email). Note that only the href “mailto:” attribute is protected. If the link text also contains the email address, then the email address is additionally exposed as plain text, and you’ll need to layer on at least one of the plain-text obfuscation techniques.

2.1 No protection

Blocked 0% of 299 spammers

HTML

<a href="mailto:am@email.spencermortensen.com">email</a>

Browser

2.2 HTML entities

Blocked 100% of 299 spammers

HTML

<a href="mailto:an@email.spencermortensen.com">email</a>

Browser

2.3 URL encoding

Blocked 96% of 299 spammers

HTML

<a href="mailto:%61%6f%40%65%6d%61%69%6c%2e%73%70%65%6e%63%65%72%6d%6f%72%74%65%6e%73%65%6e%2e%63%6f%6d">email</a>

Browser

Server-side libraries make it trivial to undo URL encoding, so this technique is essentially worthless—and, yet, it still stops most harvesters.

2.4 HTTP redirect

Blocked 100% of 299 spammers

HTML

<a rel="nofollow, noindex" href="email/">email</a>

.htaccess

RewriteEngine On RewriteRule ^email/$ 'mailto:email@example.com' [R=302,L]

.htaccess

RewriteEngine On RewriteRule ^email/$ 'mailto:email@example.com?subject=Hi' [R=302,QSA,L]

Browser

This technique turns a “mailto:” link into a regular link, without breaking its mail capability, and hides it among the other links on the page.

If you’re planning to fill out any of the fields of the email, then you should use the second form of the “.htaccess” file (with the QSA flag included) to ensure that the query string is preserved.

Because the link doesn’t lead to an actual webpage, search engines might report this to you as a broken link. The “nofollow, noindex” tags prevent this by instructing search engines not to follow and index the link.

When you’re fully satisfied with the redirect, you may wish to switch from a temporary (302) redirect to a permanent (301) redirect. After you’ve loaded a permanent (301) redirect, your browser will ignore any further changes that you make. This makes further testing more difficult, but it can make the redirect faster.

2.5 HTML SVG

Blocked 100% of 299 spammers

HTML

<object class="email" width="33" height="24" data="email.svg" type="image/svg+xml"></object>

SVG: email.svg

<svg viewBox="0 0 33 24" xmlns="http://www.w3.org/2000/svg"> <style> @import url('https://fonts.googleapis.com/css2?family=Indie+Flower&display=swap'); text { dominant-baseline: middle; fill: #000; font-family: 'Indie Flower'; font-size: 16px; text-anchor: middle; } </style> <a href="mailto:email@example.com"> <text x="50%" y="50%">email</text> </a> </svg>

CSS

object.email { height: 2em; margin: -1em 0; vertical-align: middle; }

Browser

Inspiration: rouninmedia.github.io

This hides the email address in an unusual place where most harvesters won’t think to look. However, the email address is stored there in plain text.

2.6 Concatenation JS

Blocked 100% of 299 spammers

HTML

<script>document.write('<a href="mailto:'+'a'+'p'+'@'+'e'+'m'+'a'+'i'+'l'+'.'+'s'+'p'+'e'+'n'+'c'+'e'+'r'+'m'+'o'+'r'+'t'+'e'+'n'+'s'+'e'+'n'+'.'+'c'+'o'+'m'+'">email</a>');</script>

Browser

This is convenient because it has no external dependencies, and yet still manages to block most harvesters. However, the full email address appears directly in the HTML, so this technique cannot be considered safe.

2.7 Rot18 JS

Blocked 100% of 299 spammers

HTML

<a class="email" href="znvygb:nd@rznvy.fcraprezbegrafra.pbz">email</a>

HTML

<head> <script src="[link-rot18.js](https://spencermortensen.com/articles/email-obfuscation/files/link-rot18.js)" defer></script> </head>

Browser

2.8 Conversion JS

Blocked 100% of 299 spammers

HTML

<a id="link-conversion" rel="nofollow, noindex" href="to-email-spencer/">email</a>

HTML

<head> <script src="[link-conversion.js](https://spencermortensen.com/articles/email-obfuscation/files/link-conversion.js)" defer></script> </head>

Browser

In this technique, the HTML source code contains a decoy link, and you write a custom function that converts that decoy link into a working “mailto” link.

Most harvesters can only access the HTML source code—and the source code contains nothing of value. The only practical way to restore the “mailto” link is to run your custom conversion function in a web client with DOM and JavaScript support. This is not possible for most harvesters.

You can write a custom function for each email address, or you can write a single function and apply it to all of the email addresses on the page.

Despite being frighteningly simple, this is expected to be one of the very best techniques.

2.9 JS AES encryption

Blocked 100% of 299 spammers

HTML

<a class="email" rel="nofollow, noindex" href="xd7L-AOA9Qckl5RXbFuFw8LxuiPZPk3vzyPS55-KlD-a78c00rng">email</a>

HTML

<head> <script src="[link-aes.js](https://spencermortensen.com/articles/email-obfuscation/files/link-aes.js)" defer></script> </head>

Browser

2.10 User interaction JS

Blocked 100% of 299 spammers

HTML

<a id="link-interaction" rel="nofollow, noindex" href="to-email-spencer/">email</a>

HTML

<head> <script src="[link-interaction.js](https://spencermortensen.com/articles/email-obfuscation/files/link-interaction.js)" defer></script> </head>

Browser

This technique can be used to trigger other techniques.

3 Observations

Most harvesters are easily defeated

Every obfuscation technique can be broken, so some people assume that there is no point to obfuscation. Nothing could be further from the truth! Most harvesters are unsophisticated, and even the simplest techniques are unreasonably effective at defeating them.

Harvesters follow leads more than links

Harvesters often jump straight to the high-traffic pages, ignoring low-traffic pages and links. As a result, some pages are very rarely or never seen by harvesters, which can lead people to falsely believe that no pages ever need protection. This is false, and dangerous, since a page can suddenly go viral.

4 Methodology

This article is not only an article for human readers, it’s also a honeypot for harvesters. Each technique is protecting an email address: When that address receives spam, I know which technique was broken. I make a list of which addresses each spammer knows, and I use that list to build up the statistics.

In order to reliably collect statistics, I’ve had to disable spam filtering at every step along the way. The big mail providers filter out a huge amount amount of spam that never reaches their users (some of it appears in the Spam folder, and some of it is silently deleted and never shown). Desktop mail clients often do something similar. As a result, I’ve set up my own mail server and client.

I deduplicate messages as best I can, so the statistics won’t be distorted by arbitrary details like the volume of email that a spammer sends. I keep track of which email addresses the spammer knows, and nothing else. This is a lot harder than it looks, because spammers often try to conceal their identities!

Harvesters generally don’t target both plain-text address and clickable links, so I keep those statistics independently: That’s why the total spammer counts are different for text-based and link-based obfuscation techniques.

There is some uncertainty in the statistics because the sample sizes are still relatively small. (Small, but growing.) The more people link to this article, the better these statistics will become!

Hacker Times

Hacker Times

Email obfuscation: What works in 2026?

Discussion

Discussion

1 Plain text

1.1 No protection

1.2 HTML Entities

1.4 HTML SVG

1.5 CSS Display none

1.6 JS Concatenation

1.7 JS Rot18

1.8 JS Conversion

1.9 JS AES encryption

1.10 JS User interaction

1.11 HTML Symbol substitution

1.12 HTML Instructions

1.13 HTML Image

1.14 CSS Content

1.15 CSS Text direction

2 Clickable link

2.1 No protection

2.2 HTML entities

2.3 URL encoding

2.4 HTTP redirect

2.5 HTML SVG

2.6 Concatenation JS

2.7 Rot18 JS

2.8 Conversion JS

2.9 JS AES encryption

2.10 User interaction JS

3 Observations

Most harvesters are easily defeated

Harvesters follow leads more than links

4 Methodology