Email Obfuscator: Hide Addresses From Spam Bots Without Hiding Them From People
Turn email addresses into spam-resistant forms with HTML entity encoding, ROT13 document.write snippets, and human-readable [at]/[dot] text. Copy-paste output, 100% client-side.
![A source email address card fanning out into three obfuscated flavor cards for HTML entities, ROT13 script, and human-readable [at] and [dot] text, next to a spam-bot robot crossed out by a red line](/blog/email-obfuscator-guide.svg)
Table of Contents
Email Obfuscator: Hide Addresses From Spam Bots Without Hiding Them From People
Publish an email address in plain text and the countdown starts. Harvesting crawlers extract anything shaped like [email protected] and feed it into mailing lists within days. An inbox quiet on Monday receives unsolicited offers the following week, and once an address lands on a sold-and-resold list, nothing pulls it back.
Plain mailto: links are the worst offender: scrapers match the pattern in your markup and move on. The countermeasure is obfuscation — rewrite the address so a human can still read or reconstruct it while an automated pattern match comes up empty. Email Obfuscator produces three such flavors in one pass — HTML entity encoding, a ROT13 document.write snippet, and human-readable [at]/[dot] text — each with a one-click copy-paste snippet, and everything runs in your browser.
Why Use Email Obfuscator?
- Break the cheapest harvesters: Most scraping is a regex over raw HTML. Encoding the address means the literal @ and dot pattern never appears in your source.
- Keep the page readable for humans: Browsers decode HTML entities automatically, so visitors see a normal, clickable address even though the markup is scrambled.
- Protect static sites without a backend: A single pasted snippet works on GitHub Pages, a portfolio, or any CMS that accepts raw HTML.
- Choose the trade-off that fits the context: Three flavors cover pixel-perfect rendering, script-based hiding, and plain text that survives any medium.
- Stay private by design: The tool is 100% client-side. The address never leaves your device — which matters when the address itself is the sensitive input.
Key Features
| Feature | What it does | Why it matters |
|---|---|---|
| HTML entity encoding | Rewrites every character as decimal or hex numeric entities | No literal email pattern in the markup, identical look |
| ROT13 plus script | Encodes the whole anchor tag, rebuilt by document.write | Even the tag structure is invisible to source scrapers |
| Human-readable text | Converts to name [at] domain [dot] tld | Survives plain-text contexts where markup cannot |
| Custom display text | Shows a friendly label instead of the raw address | Pages stay clean while the mailto target stays correct |
| One-click copy snippets | Every flavor is a ready-to-paste fragment | No manual encoding or syntax errors |
| Client-side only | All encoding happens in the browser | The address never touches a server |
- Instant validation: The format is checked as you type, flagging typos before anything is generated.
- Two entity variants: Pick decimal or hexadecimal entities to match your codebase conventions.
How to Use
- Open the tool: Visit Email Obfuscator in your browser. No account, no installation.
- Enter the email address: Type the address you want to protect. The tool validates the format before generating output.
- Optionally set display text: Leave it empty to show the address itself, or enter a label such as "Support Team" to keep the visible text tidy.
- Pick a flavor: Choose decimal or hex entities, the ROT13 script snippet, or plain [at]/[dot] text depending on where the snippet will live.
- Copy and paste: Drop the snippet into your HTML, README, or plain-text page, then test the result before publishing.
Three Flavors of Hiding
The three outputs are not interchangeable: each encodes a different property of the address and fails in a different way. Know what you are trading.
HTML entity encoding replaces every character of the address — and of the mailto: link — with a numeric entity. For [email protected], the markup becomes a stream like jane@..., with the anchor tag built from such codes. Browsers decode entities before rendering, so the page shows a normal, clickable address identical to the plain version; the source, however, lacks the name@domain pattern a naive scraper matches. This is the best default for most pages — zero JavaScript, zero visual difference.
ROT13 plus document.write goes further by hiding the entire anchor tag. The complete <a href="mailto:..."> element is ROT13-encoded — every letter shifted thirteen places, turning [email protected] into [email protected] — and embedded in a small script. On page load the script reverses the shift and writes the real link into the DOM. A scraper reading only the raw source sees no email-shaped text; the address exists only after JavaScript executes.
Human-readable [at]/[dot] text turns the address into prose: jane [at] example [dot] com. Nothing decodes it automatically — the reader reconstructs it in their head. It works everywhere: plain-text files, PDFs, flyers, raw READMEs. The trade-off is usability: no clickable mailto: link, copy-paste yields the obfuscated text, and screen readers may announce the brackets verbatim. Reserve it for contexts where markup is not an option.
Honest limits: none of these stops a determined adversary. Scrapers that render pages or decode encodings will recover all three flavors. Obfuscation raises the cost of casual harvesting; it does not provide security. For high-value inboxes, combine it with spam filtering or a contact form, and rotate already-leaked addresses.
Practical Use Cases
Contact pages
The classic case. A small business wants a reachable address on its contact page but watches it get harvested within a week. Entity encoding keeps the page exactly as usable as before while removing the pattern harvesters match. For a footer address repeated site-wide, encode once and reuse the snippet.
Team listings
An "Our Team" section often lists a dozen addresses, multiplying exposure. Use the custom display text option: show each person's name as the link while the encoded mailto: target carries the address. Visitors get a clean listing; scrapers get nothing readable.
Open-source READMEs
Project READMEs render as HTML on most forges but also exist as raw plain text in mirrors and terminal views. The [at]/[dot] flavor is the natural fit: legible in every context, no script needed, and a long-standing open-source convention.
Personal sites and portfolios
A portfolio is a static page hosted for years with little maintenance — exactly where a quietly leaking address goes unnoticed. A ROT13 snippet or entity-encoded link protects it with zero upkeep.
Best Practices
- Prefer a contact form for high-traffic pages: A page drawing heavy search traffic attracts sophisticated scrapers. A server-side form with rate limiting protects better than any client-side encoding.
- Test the rendered result before publishing: Load the page, click the link, and check the mailto target. Encoding mistakes are invisible in the source but obvious in the browser.
- Pair with server-side defenses: Rate limiting and spam filtering complement obfuscation; the layers catch what the other misses.
- Match the flavor to the medium: Entities for HTML pages, ROT13 to hide the whole link, [at]/[dot] for plain text.
- Rotate already-published addresses: Obfuscating an address after it was exposed unobfuscated will not remove it from existing lists. Issue a new one and update the page.
- Remember it is deterrence, not security: Obfuscation filters opportunistic harvesters. Treat any address on a public page as eventually discoverable.
Protect the Address, Keep the Page Friendly
An inbox is harder to change than a line of HTML. Before you publish the next contact page or README, open Email Obfuscator, paste the address, pick the flavor that fits the medium, and copy the snippet. It runs entirely in your browser and turns the easiest harvest on the web into a dead end.
Related Tools You Might Like:
- PII Redactor — strip emails, cards, and keys from text before you paste or share it.
- QR Generator — share contact details as a scannable code instead of a scrapeable address.
- Text Case Converter — clean up labels and display text around your snippets.
Happy publishing, and quieter inboxes!
Frequently Asked Questions
Q: Does Email Obfuscator upload my email address anywhere?
A: No. All encoding happens locally in your browser; the address never leaves your device.
Q: Which flavor should I use on a normal website?
A: HTML entity encoding is the best default. It renders identically to a plain address, requires no JavaScript, and defeats the source-scraping pattern most harvesters rely on. Use ROT13 when you want the whole anchor tag hidden from source readers.
Q: Will obfuscated emails still work with screen readers?
A: Entity-encoded and ROT13 links do, because the browser decodes them into a normal link before assistive technology reads the page. The [at]/[dot] text flavor does not — screen readers may read the brackets literally.
Q: How long does obfuscation actually delay spam?
A: It stops most cheap, pattern-based crawlers immediately, but dedicated harvesters that render pages or decode entities will recover the address. Think of it as raising the barrier, not building a wall.
Q: Can I obfuscate several addresses at once?
A: The tool processes one address at a time. For a team listing, generate a snippet per address and paste them together.