How AI Harvesters See Your 'Hidden' Email
Historically, email obfuscation was about making it hard for regex-based bots to find user@domain.com patterns. HTML entities (me@...), comments, even simple JavaScript concatenation ('me' + '@' + 'domain.com') were enough. And for the vast majority of harvesters, they still are. Our data, updated as recently as January 30, 2026, shows techniques like HTML entities blocking 95% of plain text harvesters, and 100% for clickable links. HTML comments hit 98%. Even basic JS concatenation and Rot18 block 100% of the tested spammers.
But here's the thing: those numbers are against unsophisticated harvesters. The problem isn't the volume of simple bots; it's the capability of the advanced ones. When you've got a GenAI-powered scraper, running on something like llama.cpp with Mistral Small 3.1, it's not just looking for patterns. It's interpreting context. It's reading the page like a human. It can execute JavaScript, understand CSS rules, and even infer an email address from "me at foobar dot com" if it's not properly hidden.
This is where the "human-readable obfuscation" methods fall apart. An LLM can easily parse "me at foobar dot com" or even reverse simple symbol substitutions. It's not just about string manipulation anymore; it's about semantic understanding.
Building Walls That AI Can't Just Read Through
So, if AI can read like a human, how do you hide from it? You make it act like a human. The techniques that consistently block 100% of harvesters, even in this new landscape, are those that either:
- Require active interpretation beyond simple parsing.
- Demand user interaction.
- Render the email in a non-textual, non-searchable format.
Let's break down what's actually holding up:
- HTML SVG: This one's interesting. You embed the email within an SVG object. The email is still in plain text within the SVG, but it's not directly in the main HTML flow. It's accessible to screen readers, which is good for usability, but it requires an
<object>element. The key here is that most harvesters aren't designed to dive into SVG objects and extract text. - CSS
display: none: This hides the email visually. Most harvesters don't apply style rules, so they won't see it. It's fully accessible to screen readers. The catch? Harvesters can recover it from the HTML alone if they're smart enough to ignore the CSS. But for many, it's a barrier. - JS Conversion: This is where you put gibberish in the HTML source, and a custom JavaScript function converts it into the actual email address. For clickable links, it converts a decoy link to a
mailto:link. This is expected to be one of the best techniques because the email never appears in plain text in the initial HTML. - JS AES encryption: This uses AES 256 encryption. The email cannot be recovered without the JavaScript file that decrypts it. It uses the browser's
SubtleCryptolibrary, which means you need a secure context (HTTPS or localhost). This is a strong contender because it's not just obfuscation; it's encryption. - JS User interaction: This is a high bar. The email is hidden until a user clicks a button, hovers, or performs some other action. This forces a harvester to act like a full web client and simulate user interaction, which significantly increases its complexity and resource cost.
- HTML Image: Just an image of the email. Inconvenient for users, inaccessible without good alt text, but effective against bots.
- SVG with Text Converted to Curves: This renders text as vectors, not searchable text. It's effective because it's not text for the scraper to read.
And then there's Plus-Addressing (me+someservice@somedomain.com). This isn't obfuscation in the traditional sense, but it's a powerful defense. It lets you create unique addresses for different services. If one gets leaked, you know exactly who sold you out, and you can block that specific address. Some spammers might strip the +postfix, but it still forces them to guess, and some users configure their inboxes to only accept plus-addressed mail.
The Usability Tax and the Bigger Picture
The trade-off here is always usability versus protection. Techniques like HTML Image or HTML Instructions (which only a human or AI can break, but break usability) are 100% effective, but they're a pain for legitimate users. You have to balance that. My advice? Don't just pick one. Layer them.
For organizations, the primary source of bulk spam isn't web harvesting anymore; it's large data breaches. So, while obfuscation helps, it's not a silver bullet. You still need strong internal security, good data hygiene, and robust spam filtering.
Speaking of spam filtering, the good news is that LLM-based spam filters are incredibly effective. Tools using local models like gpt-oss:20b or Mistral Small 3.1 are reporting >97% accuracy. So, even if some addresses get harvested, the impact on the end-user's inbox can be mitigated.
Email obfuscation isn't dead in 2026, but the rules have changed. Simple string manipulation is a speed bump for AI, not a wall. If you're serious about protecting an email address on a public page, you need a multi-layered approach that uses JavaScript for dynamic rendering, encryption, or user interaction. And for critical contacts, consider non-textual rendering like SVG with text converted to curves. Don't rely on a single trick. The goal isn't to be unbreakable; it's to make harvesting you so expensive and complex that it's not worth the attacker's time. That's the fight we're in, and it's one we can still win with smart, adaptive defenses.
