Free Email Obfuscator

How spam bots harvest emails (and why obfuscation works)

A spam harvester is just a script that fetches your page and runs a regex on the HTML. A common one: `[a-zA-Z0-9._-]+@[a-zA-Z0-9._-]+\.[a-zA-Z]{2,}`. Anything that matches that pattern, the bot scrapes into a list. That list gets sold to spammers, traded in forums, or fed into automated cold-email campaigns.

The whole job takes the bot a few milliseconds per page. They process millions of pages a day.

Obfuscation works by breaking the pattern the bot looks for. If the regex searches for `@`, we hide it as `@` or assemble it from JavaScript fragments at page load. The bot's regex misses it. The visitor's browser decodes everything normally and sees a clickable link.

Studies from MIT's CSAIL Lab (2003, still the most-cited research on this) found basic HTML entity obfuscation alone reduced incoming spam by 88% in their test domains. ROT13 with a JS decoder dropped it to 99%+. Modern bots have caught up to entity decoding, but JS-based methods still defeat most automated scrapers.

The six methods, in plain English

Use the dropdown in the tool above to switch between methods. Each one has different trade-offs:

1. HTML character entities

Every character in the email becomes its HTML hex code. `kevin@example.com` turns into `kev…`. The browser decodes entities at HTML parse time, so the link still works perfectly. No JavaScript needed. Fully accessible. Bots that only run regex against raw HTML miss it.

The downside: modern crawlers do parse HTML entities. Treat this as your baseline level of protection, not your bunker.

2. JavaScript Unicode escape

Each character is written as a `\u` escape sequence inside a JavaScript string. A tiny inline `<script>` writes the link to the page at runtime. Bots that skip JavaScript (most spam crawlers do) see escape sequences inside script tags they ignore. Browsers decode in milliseconds.

3. JavaScript split and concat

The email is broken into fragments stored in separate JavaScript variables (`var a = "kev", b = "in"`), then concatenated at runtime. Same protection as the Unicode method but easier to read in source — useful when you're debugging your site and want to spot the obfuscation quickly.

4. ROT13 + JS decoder (recommended)

Each letter shifts by 13 positions. `kevin@example.com` becomes `xrivaaa@rknzcyr.pbz`. The encoded string doesn't match an email regex at all — it looks like random text. A small decoder runs on page load, reverses the shift, and replaces the placeholder with a working `mailto:` link.

This is the strongest CLICKABLE method we offer. If you want the best balance of protection and UX, use this one.

5. Data attribute + base64

The email gets base64-encoded and stored in a `data-e` attribute. The link's `href` starts as `#`. When the visitor clicks, an inline handler decodes the base64 and rewrites the href to the real `mailto:` URL. The cleanest, most modern HTML output of the JS methods — screen readers see the link text correctly, bots see gibberish in a data attribute.

6. Canvas image

The email is drawn as a PNG image using HTML5 canvas, embedded as a `data:` URL in an `<img>` tag. Bots would need OCR to read the address, and virtually none do. Maximum protection. The trade-off: the email isn't a clickable link, isn't selectable, and screen readers can't announce it. Visitors have to type the address into their compose window manually.

Use this when bot resistance matters more than convenience — a footer contact email at a high-traffic site, for example.

Picking the right method (a decision guide)

Stop reading and answer one question:

When in doubt, use ROT13 (method 4)

It's clickable, accessible to screen readers, defeats almost every automated harvester, and works in every modern browser back to IE9. Unless you have a specific reason to pick something else, default to this.

Adding obfuscated email to your site

The output is plain HTML with optional inline JavaScript. It works in every CMS that allows raw HTML embeds. Here's how to add it to the common platforms:

WordPress

1. Open the page or post in the Gutenberg editor.
2. Add a Custom HTML block where you want the email to appear.
3. Paste the snippet from this tool. Click Preview to confirm it renders correctly.
4. For Classic Editor: switch to the Text tab and paste the HTML there.
5. For widget areas (sidebar, footer): use the Custom HTML widget.

Shopify

1. In the theme editor, find the section where the email should appear (often "Contact" or "Footer").
2. Add a Custom Liquid block to that section.
3. Paste the obfuscator snippet directly. Liquid allows raw HTML — no escaping needed.
4. For theme-wide changes, edit `theme.liquid` directly via Online Store → Themes → Edit code.

Webflow

1. Open the Designer.
2. Drag an Embed element (Components panel → Embed) into the page.
3. Paste the snippet into the embed editor.
4. Publish — the obfuscated email renders correctly on the live site.

Squarespace, Wix, Ghost, plain HTML

Any CMS that supports raw HTML blocks works. The snippet is self-contained — no external CSS or JS dependencies, no extra setup. Paste and go.

What obfuscation can't protect against

Be honest about the limits. Obfuscation reduces automated harvesting, but it's not a security boundary:

• Determined humans can still find your email. Anyone who visits your page and copies it from the rendered link has your address. Obfuscation defeats scripts, not people.
• Sophisticated bots can run JavaScript. A spam operation specifically targeting your site (rare but possible) can defeat methods 2-5 by executing scripts before scraping. Method 6 (image) holds up against those too.
• Your email leaks in other ways. Once you reply to a public mailing list, post to a forum with your email visible, or hit a contact form that gets compromised, the address is out. Obfuscation on your own site doesn't help.
• Old email lists already have you. If your address was on the web unobfuscated for years, it's almost certainly already in spam databases. Obfuscation slows new harvesting; it doesn't undo old.

When to use a contact form instead

Email obfuscation is the right call when you want a clickable email link on your page. It's the wrong call when:

• You get enough volume that managing replies in your personal inbox isn't viable. A contact form routes to a help-desk or CRM where it can be triaged.
• You want to capture structured data — name, company, request type. A contact form has fields. An email doesn't enforce anything.
• You never want your email exposed at all. A contact form keeps your address completely private — the submission goes through your form handler, you reply from your account, the visitor never sees the raw address.

For most personal sites, freelance portfolios, and small businesses, obfuscation is plenty. For larger operations, a form is usually the right call.

Five common mistakes to avoid

1. Putting your email in `alt` text on an image. Bots read alt attributes. If you obfuscate the visible email but leave `alt="kevin@example.com"`, the alt undoes everything.

2. Leaving your email plain in your DKIM/SPF records. Your DNS TXT records are public. Scrapers query them directly. Use a separate mailbox (no-reply, abuse, etc.) in DNS records, not your personal address.

3. Obfuscating one email but linking it from many pages with the email in the URL. If your contact page is at `example.com/contact-kevin@example.com.html`, the URL itself leaks the address. Use a slug, not the email.

4. Trusting a single method against all bots. Use different methods on different parts of your site. If a scraper figures out one, it doesn't automatically get the others.

5. Forgetting that browser extensions can decode anything. Some "harvest emails from page" browser extensions decode every method on this page in real time. They're used by individual researchers and salespeople, not bulk spam operations — but if you want to be invisible to them, use the canvas method (#6) or a contact form.

Beyond obfuscation: keeping inboxes healthy

Obfuscation protects the address you expose on your site. Two related habits keep your inboxes healthy whether or not your address gets harvested:

Verify the emails you collect. When visitors send through obfuscated links, you reply to whatever they sent — including invalid or disposable addresses. Run new contacts through our email verifier before adding them to a list. Three free checks per day, 200 free credits on signup.

Validate addresses on your forms. If you have a contact form or newsletter signup, validate the email syntax client-side before letting the form submit. Our email syntax checker shows you how RFC 5322 validation should work — use the same rules in your form code.

Extract emails from documents the safe way. If you have a long contract, RFP, or list with emails scattered through, our email extractor pulls them out, dedups them, and exports a clean list — without you having to scroll through manually.