Email address obfuscation: What works in 2026?
- Last updated:
- August 8, 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.
Ideally, you would be using more than one technique in combination. For example, you could split the email address into two parts, where each part is protected by a different technique. That way, a harvester would have to break both techniques in order to recover the email address.
1 Plain text
These techniques protect an email address written out in plain text (e.g. “email@example.com”).
1.1 No protection
aa@email.spencermortensen.com
1.2 HTML Entities
ab@email.spencermortensen.com
Server-side libraries often decode HTML entities automatically, so this technique should be worthless—and, yet, it somehow stops most harvesters.
1.3 HTML Comments
ac@email.spencermortensen<!--.example--> .com
This will stop only the most basic harvesters that struggle with HTML tags. It offers minimal protection—and, yet, it somehow stops most harvesters.
1.4 HTML SVG
<object class="email" width="130" height="24" data="email.svg" type="image/svg+xml"></object>
<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>
object.email {
height: 2em;
margin: -1em 0;
vertical-align: middle;
}
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
<div class="email">ad@<span>email.</span>spencermortensen.<span>example.</span>com</div>
div.email > span:nth-child(2) {
display: none;
}
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
<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>
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
<span class="email">nw@rznvy.fcraprezbegrafra.pbz</span>
<head>
<script src="text-rot18.js" defer></script>
</head>
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
<span id="text-conversion">zibby example com</span>
<head>
<script src="text-conversion.js" defer></script>
</head>
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.
Despite being frighteningly simple, this is expected to be one of the very best techniques.
1.9 JS AES encryption
<span class="email">Kreuz2xa6xB8Fpjaa0lFgACNLO6n_Auu1CGjcG8z_Ec</span>
<head>
<script src="text-aes.js" defer></script>
</head>
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. If you’re using http, you’ll need to upgrade to https in order to use this technique!
1.10 JS User interaction
<span id="text-interaction">whose baby example com</span>
<head>
<script src="text-interaction.js" defer></script>
</head>
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
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
au.fluff@email.spencermortensen.com (remove the “.fluff” before writing to me)
(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
<img src="email.jpg" width="216" height="18" alt="email address">
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
<span class="email" data-user="af" data-domain="email.spencermortensen.com" ></span>
span.email::after {
content: attr(data-user) '@' attr(data-domain);
}
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
<span class="email">moc.nesnetromrecneps.liame@ea</span>
span.email {
unicode-bidi: bidi-override;
direction: rtl;
}
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
<a href="mailto:am@email.spencermortensen.com" >email</a>
2.2 HTML entities
<a href="mailto:an@email.spencermortensen.com" >email</a>
Server-side libraries often decode HTML entities automatically, so this technique should be worthless—and, yet, it somehow stops most harvesters.
2.3 URL encoding
<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>
Server-side libraries make it trivial to undo URL encoding, so this technique should be worthless—and, yet, it somehow stops most harvesters.
2.4 HTTP redirect
<a rel="nofollow, noindex" href="email/">email</a>
RewriteEngine On
RewriteRule ^email/$ 'mailto:email@example.com' [R=302,L]
RewriteEngine On
RewriteRule ^email/$ 'mailto:email@example.com?subject=Hi' [R=302,QSA,L]
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 or 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 in production.
2.5 HTML SVG
<object class="email" width="33" height="24" data="email.svg" type="image/svg+xml"></object>
<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>
object.email {
height: 2em;
margin: -1em 0;
vertical-align: middle;
}
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.
2.6 Concatenation JS
<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>
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
<a class="email" href="znvygb:nd@rznvy.fcraprezbegrafra.pbz" >email</a>
<head>
<script src="link-rot18.js" defer></script>
</head>
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.
2.8 Conversion JS
<a id="link-conversion" rel="nofollow, noindex" href="to-email-spencer/" >email</a>
<head>
<script src="link-conversion.js" defer></script>
</head>
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.
Despite being frighteningly simple, this is expected to be one of the very best techniques.
2.9 JS AES encryption
<a class="email" rel="nofollow, noindex" href="xd7L-AOA9Qckl5RXbFuFw8LxuiPZPk3vzyPS55-KlD-a78c00rng" >email</a>
<head>
<script src="link-aes.js" defer></script>
</head>
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. If you’re using http, you’ll need to upgrade to https in order to use this technique!
2.10 User interaction JS
<a id="link-interaction" rel="nofollow, noindex" href="to-email-spencer/" >email</a>
<head>
<script src="link-interaction.js" defer></script>
</head>
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.
3 Criticisms
Spammers buy and sell email addresses stolen in data breaches; they don’t scrape the web anymore.
The email addresses in this article have never been in any database. They get tens of thousands of spam messages.
My email address is unprotected on the web, and I never get spam.
Harvesters don’t spend equal time on every web page: viral content is heavily scrutinized, while all other content is largely ignored. Because an article can suddenly go viral, it’s dangerous to assume that you won’t need protection just because you haven’t needed it so far.
I know a way to break a technique, so it’s pointless to use it.
Harvesters struggle with the simplest things, such as reading HTML comments and decoding HTML entities. Even the most easily-defeated technique will block nearly all spam.
All you really need is a good spam filter.
Unlike spam filters, these techniques have no false positives, are simple to set up, and are extremely effective: Why wouldn’t you use them?
If spammers read your article, they’ll learn to break our defenses.
Most of these techniques have been common knowledge for a very long time. We have statistics on their effectiveness going back decades, in some cases. For whatever reason, these techniques are just as effective now as they were back then.
4 Methodology
This article isn’t just for human readers, it’s also a honeypot for harvesters. Each technique is protecting a unique email address: When an address receives spam, I know that a harvester broke that technique. (From there, the email address may wind up in the hands of many different spammers, because spammers sometimes buy and sell their email lists.) I make a list of the addresses that each spammer knows, and I use that list to infer which addresses the spammer does not know. This gives me the list of the techniques that defeated the underlying harvester.
I group messages by spammer, so the statistics won’t be distorted by arbitrary details, such as the volume of email that a spammer just happens to send. This is a lot harder than it looks, because spammers often try to conceal their identities to sneak around censorship. My system isn’t perfect, but I do my very best to count only spammers, not their aliases or their messages.
Harvesters usually target either plain-text addresses or clickable links, but rarely both—so I keep those statistics independently: That’s why the total spammer counts are different for the text-based and link-based techniques.
Some of the big mail providers silently discard clear-cut spam without ever showing it to you, putting only suspected spam in your spam folder. So, before collecting any statistics, I had to first disable all upstream spam filtering. I set up a custom mail server, and a custom mail client, just for this project.
There is some uncertainty in the statistics because the sample sizes are still relatively small. However, the more people link to this article, the more harvesters will see it, and the better these statistics will become!