Email Obfuscator
Turn your email address into scraper-resistant HTML — entities, JavaScript, CSS reversal, or a ROT13 mailto — that bots can't harvest but people can still click. Runs entirely in your browser.
About this tool
Spam bots crawl the web and scrape email addresses out of page source — every
plain [email protected] or mailto: link is fair game for an address harvester.
The Email Obfuscator rewrites your address into HTML that a regex scraper
can't read, while a real browser still renders it (and, optionally, keeps it
clickable). Everything runs locally in your browser; your address is never sent
to a server.
Obfuscation modes
- HTML entities (default) — every character becomes a numeric character
reference, e.g.
[email protected]→you…. The browser shows the original text; a scraper sees only entities. Choose decimal (j) or hexadecimal (j) radix. - JavaScript — emits a
<script>that builds the address from character codes at run time withdocument.write, so the address never appears as a literal in the served HTML at all. A<noscript>entity-encoded fallback keeps it reachable without JavaScript. - CSS reversal — prints the address backwards in the source and flips it
back visually with
unicode-bidi: bidi-override; direction: rtl. A scraper readsmoc.elpmaxe@uoy; visitors see[email protected]. - ROT13 mailto — a
mailto:link whosehrefis ROT13-scrambled and decoded by a tiny inlineonclickhandler the moment a visitor clicks it (the classic WordPress-style trick).
How to use
- Type the email address you want to protect.
- Pick an obfuscation mode (and, for entity output, decimal or hex).
- Optionally turn off the clickable
mailto:link, or set custom link text such as "Email us". - Copy the generated HTML and paste it into your page.
Notes
- Obfuscation slows down automated scrapers; it is not encryption. For high-value inboxes, pair it with a contact form or a server-side relay.
- The address is validated as
local@domainwith a dotted domain before encoding, so typos are caught early. - All four modes leave the address usable by humans — entities and CSS render normally, and the JS/ROT13 modes degrade to an entity-encoded fallback.
FAQ
Which obfuscation mode should I pick?
Entities (the default) is the safest all-rounder — it needs no JavaScript and
keeps the mailto link clickable. JavaScript is the strongest against scrapers
because the address never appears as a literal in the served HTML, but it depends
on JS (a <noscript> entity fallback is included). CSS reversal is great for
display-only addresses, and ROT13 mailto is the classic trick when you mainly
care about protecting the href.
Why doesn't the CSS mode give me a clickable link?
Because the trick works by printing the address backwards and flipping it visually
with unicode-bidi: bidi-override — a reversed mailto: href wouldn't work when
clicked. CSS mode therefore always emits display text only; use entities, JS, or
ROT13 mode if you need a working link.
Does this actually stop spam?
It defeats the regex-based harvesters that account for most address scraping, but it is obfuscation, not encryption — a bot that executes JavaScript or decodes entities can still recover the address. For a high-value inbox, combine it with a contact form or a server-side relay.
Why does it say my email address is invalid?
The address is checked as local@domain with a dotted domain (e.g.
[email protected]) before encoding, so a missing @ or a bare domain like
you@localhost is rejected — better to catch the typo here than to publish
obfuscated HTML of a broken address.
Developer & Automation Access
Run it from the terminal
Same engine as this page, headless — via the gizza CLI:
gizza tool email-obfuscator "[email protected]"New to the CLI? Get gizza →
Open it by URL
Pre-fill and auto-run this tool with query parameters — the names match the API/CLI:
https://gizza.ai/tools/email-obfuscator/?email=you%40example.com&mode=entities&entity_style=decimal&link=true&link_text=Email%20usMachine-readable descriptor: tool.json — title + parameters JSON Schema for agents.