Morgan AldridgeApr 2
Tim Chase

An interesting article¹ by Spencer Mortensen on obfuscating email addresses on web-pages, detailing how well each technique has worked.

While all the more advanced techniques had much higher blocking-success, I dislike how they rely on CSS or JavaScript which breaks in most of the simple text-mode browsers. For inline-text email addresses, the comment method

me@examp<!-- comment -->le.com

seemed to hit the sweet-spot of working in all browsers, yet effectively eliminating 98% of spamming attempts.

However, that doesn't appear to work in a mailto: link,

<a href="me@examp<!-- comment -->le.com">Contact me</a>

so it might make more sense to use the Entities method in that case:

<a href="mailto:&#109;&#101;&#64;&#101;&#120;&#97;&#109;&#112;&#108;&#101;&#46;&#99;&#111;&#109;">Contact me</a>

⸻
¹ https://spencermortensen.com/articles/email-obfuscation/

Email address obfuscation: What works in 2026?

Apr 2 at 1:52pmWeb
Show threadReayApr 2
@gumnos @Binder
@FirewallDragons
Show threadChris Mackay 🇨🇦Apr 2
@gumnos Using a form works 100% of the time, eliminates the game of whack-a-mole with spammers, and doesn’t require the user to have a configured email client (or remember their webmail login) if they’re using a shared computer (e.g. library PC).
Show threadMorgan AldridgeApr 2

@tantramar @gumnos I'll counter that using a form has many downsides (naturally, many still shared by email):

1. Still a target for spammers, often requiring JS captchas and such
2. No guarantee the destination is checked or left to collect spam
3. Doesn't provide the user with actual contact info
4. Higher liklihood of message data loss (user must remember to copy form content before submitting because an error often results in loss of the message content)
5. Privacy concerns

Show threadChris Mackay 🇨🇦Apr 2
@morgant @gumnos 1. Website problem, not user problem
2. Not unique to either method
3. Feature (not a bug)
4. More of an issue in years past; crashiness is much reduced (I used to worry about this a lot but can’t remember the last time it bit me)
5. Not unique to either method
Show threadMorgan AldridgeApr 2

@tantramar @gumnos I wholly agree that most of these are shared problems, but I have to — respectfully — disagree on points 1. & 4.

1. JavaScript and captcha requirements are often a problem for website users (maybe just running older/lower-end hardware, limited/inconsistent Internet access, or accessibility issues due to disabilities) and the spam is still a problem for the receiving user

2. I encounter this frequently, especially on mobile devices where switching apps may cull browser tasks

Show threadMorgan AldridgeApr 2
@tantramar @gumnos Not arguing against forms, they're just better as an optional alternative as opposed to a replacement for providing an email address. I have _zero_ interest in going back to the early days of the Internet with people emailing orders, contact info, credit cards, etc.! Or, marginally better, emailing with instructions to call to provide those details.
Show threadTim ChaseApr 2

@morgant @tantramar

Forms also require server-side infrastructure that inhibits use with a static site. Yes, you can set the form target to some outsourced form-processor, but usually those then come to you…as email 😁

Show threadChris Mackay 🇨🇦Apr 2
@gumnos @morgant Very true.
Show threadChris Mackay 🇨🇦Apr 2
@morgant @gumnos There are always edge cases and we’ll never get to perfection. The sites I build tend towards simpler contact forms, and one way I mitigate against form-clearing data loss is restricting length to about 500 characters.
Show threadDrScripttApr 3
@gumnos I’ve never bothered beyond (at) / (dot) and that’s mostly just to break automatic linkification.
Show threadTim ChaseApr 3

@drscriptt

yeah, despite having wide-open blog@mydomain all over my blog, I get remarkably little spam at that address. Maybe a couple per month. But I suspect the entity-encoding would reduce that further.