Live data from Hacker News

Email obfuscation: What works in 2026?

spencermortensen.com

21–30 of 124 posts

Re: Email obfuscation: What works in 2026?

#21
post #9

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.

It also keeps visually impaired people at bay.

Re: Email obfuscation: What works in 2026?

#22
post #14

Earlier quoted context omitted.

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.

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.

Re: Email obfuscation: What works in 2026?

#24
post #13

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) wil…

> 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!

Re: Email obfuscation: What works in 2026?

#25
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

Re: Email obfuscation: What works in 2026?

#26
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.

Re: Email obfuscation: What works in 2026?

#27
post #24
post #13

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) wil…

> 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!

My email provider allows me to send from + email addresses, just change the from header.

Re: Email obfuscation: What works in 2026?

#28
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.

Re: Email obfuscation: What works in 2026?

#29

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…

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

Re: Email obfuscation: What works in 2026?

#30

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 whic…

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