tl;dr
Hide email address from bots without using scripts and maintain mailto:
functionality. Method must also support screen-readers.
Summary
Email obfuscation without using scripts or contact forms
Email address needs to be completely visible to human viewers and maintain
mailto:
functionalityEmail Address must not be in image form.
Email address must be "completely" hidden from spam-crawlers and spam-bots and any other harvester type
Desired Effect:
No scripts, please. There are no scripts used in the project and I'd like to keep it that way.
Email address is either displayed on the page or can be easily displayed after some sort of user interaction, like opening a modal.
The user can click on on the email address which in turn would trigger the
mailto:
functionality.Clicking the email will open the user's email application.
In other words,
mailto:
functionality must work.The email address in not visible or not identified as an email address to bots (This includes the page source)
I don't have an inbox that's full of spam
What does NOT Work
- Adding a contact form - or anything similar - instead of the email address
I hate contact forms. I rarely fill up a contact form. If there's no email address, I look for a phone number, and if that's not there, I start looking for an alternative service. I would only fill up a contact form if I absolutely have to.
- Replacing the address with an image of the address
This creates a HUGE disadvantage to someone using a screenreader (please remember the visually impaired in your future projects)
It also removes the mailto:
functionality unless you make the image clickable and then add the mailto:
functionality as the href
for the link, but that defeats the purpose and now the email is visible to bots.
What might work:
Clever usage of
pseudo-elements
inCSS
Solutions that make use of
base64
encodingBreaking up the email address and spreading the parts across the document then putting them back together in a modal when the user clicks a button (This will probably involve multiple
CSS
classes and the usage ofanchor tags
)Alterting
html
attributes viaCSS
@MortezaAsadi gracefully brought up the possibility in the comments below. This is the link to the full - The article is from 2012:
What if We Could Use CSS to Alter HTML Attributes?
- Other creative solutions that are beyond my scope of knowledge.
Similar Questions / Fixes
(This a great fix suggested by Joe Maller, it works well but it's script based. Here's what it looks like;
<SCRIPT TYPE="text/javascript">
emailE = 'example.com'
emailE = ('yourname' + '@' + emailE)
document.write('<A href="mailto:' + emailE + '">' + emailE + '</a>')
</script>
<NOSCRIPT>
Email address protected by JavaScript
</NOSCRIPT>
Looking for a PHP only email address obfuscator function
(A Clever solution using both
PHP
andCSS
to first reverse the email using PHP then reverse it back with CSS) A very promising solution that Works great! But it's too easy to solve.Is it worth obfuscating email addresses on the web these days?
(JavaScript fix)
The selected answer works. It actually works really well. It involves encoding the email as html entities
. Can it be improved?
Here's what it looks like;
<A HREF="mailto:
yourname@domain.com">
yourname@domain.com
</A>
(The selected answer to this SuperUser question is great and it presents a study of the amount of spam received by using different obfuscation methods.
It seems that manipulating the email address with CSS
to make it rtl
does work. This is the same method used in the first question I linked to in this section.
I am uncertain what effects adding mailto:
functionality to the fix would have on the results.
- There are also many other questions on SO which all have similar answers. I have not found anything that fits my desired effect
The Question:
Would it be possible to increase the efficiency (ie as little spam as possible) of the email obfuscation methods above by combining two or more of the fixes (or even adding new fixes) while:
A- Maintaining mailto:
functionality; and
B- Supporting screen-readers
Many of the answers and comments below pose a very good question while indicating the impossibility of doing this without some sort of js
The question that's asked/implied is:
Why not use
js
?
The answer is that I am allergic to js
Joking aside though,
The three main reasons I asked this question are:
Contact forms are becoming more and more accepted as a replacement for providing an email address - which they should not.
If it can be done without scripting then it should be done without scripting.
Curiosity: (as I am in fact using one of the
js
fixes currently) I wanted to see if discussing the matter would lead to a better way of doing it.
The issue with your request is specifically the "Supporting screen-readers", as by definition screen readers are a "bot" of some sort. If a screen-reader needs to be able to interpret the email address, then a page-crawler would be able to interpret it as well.
Also, the point of the
mailto
attribute is to be the standard of how to do email addresses on the web. Asking if there is a second way to do that is sort of asking if there is a second standard.Doing it through scripts will still have the same issue as once the page is loaded, the script would have been run and the email address rendered in the DOM (unless you populate the email address
on click
or something). Either way, screen readers will still have issues with this since it's not already loaded.Honestly, just get an email service with a half decent spam filter and specify a default subject line that is easy for you to sort in your inbox.
What you're asking for is if the standard has two ways to do something, one for bots and the other for non-bots. The answer is it doesn't, and you have to just fight the bots as best you can.