Skip to the tool
OnPageKit

Email Obfuscator

Encode mailto links and find exposed emails in HTML.

Encode a mailto link

optional
optional

Type an address to get three encoded versions to paste into your HTML.

Find exposed addresses in HTML

view source, select all, paste

The markup is read in this tab. Nothing is fetched or uploaded.

Paste HTML to scan it.

    Everything runs in your browser. Nothing you type is sent to a server.

    Found a bug in this tool? Report it.

    Share this tool

    What this tool does

    This email obfuscator does two jobs. The first turns an address into HTML you can paste into a page: a mailto link encoded as HTML entities, a mailto link with a percent-encoded address, and a CSS trick that stores the address backwards and flips it for display. All three look normal to a visitor.

    The second job runs in the other direction. Paste the source of a page and it finds plain text emails in the HTML — visible addresses, mailto: links, and addresses that were encoded but decode in one step — each with the line it sits on. That is usually the more useful half: most people who want to hide an email from spam bots have already published it in three places they forgot about.

    How to use it

    1. Type the address, and optionally the link text and a subject line.
    2. Copy the variant you want. The two link versions stay clickable; the CSS version does not.
    3. To audit a page, open its source, paste it in the lower box and work through the list. Anything marked plain is readable by the simplest harvester there is.

    Everything runs in this tab. The address you type and the markup you paste are never sent anywhere.

    How much this actually protects

    Be realistic about it. Harvesting bots range from a regex run over raw HTML to a full headless browser. The regex kind is still the most common, and it misses anything without a literal @ and dot in the source — which is exactly what entity and percent encoding remove. That is why encoded addresses measurably receive less spam than plain ones.

    A headless browser renders the page, decodes every entity and applies every CSS rule, so it sees what a visitor sees. Against that, no mailto link encoder helps, and any technique good enough to defeat it — assembling the address with JavaScript on click, or an image of the text — also costs real visitors something. If the address matters, keep it off the page: use a form, or publish a role address you can filter aggressively and retire when it gets burned.

    The three methods compared

    HTML entities replace every character with a numeric reference like @. It is the oldest trick, it keeps the link fully working, and nearly every modern harvester decodes it.

    Percent encoding writes the address inside href as %68%69%40…. Mail clients decode it as RFC 6068 requires, and a scraper looking for a literal @ walks past it.

    CSS direction stores moc.elpmaxe@olleh and sets direction: rtl with a bidi override so it displays the right way round. It is not a link, it copies backwards, and some screen readers read it in source order.

    When you audit a page for addresses, check how its outbound links are marked up too with the link attributes checker, and use the meta tag analyzer on the same pasted source for the rest of the head.

    Frequently asked questions

    Does email obfuscation still stop spam in 2026?

    Partly, and less every year. Studies that planted test addresses found that plain mailto links attract far more spam than encoded ones, because many harvesters are still simple regex scripts. But any scraper that decodes HTML entities, follows mailto links or runs the page in a headless browser reads every technique here. Treat obfuscation as a speed bump, not a lock.

    Which method should I use?

    The percent-encoded mailto is the best compromise: it stays a normal clickable link, screen readers announce it correctly, and it defeats scrapers that only look for a literal @ in the source. CSS-reversed text resists more bots but is not clickable and copies backwards, which punishes the humans you want to hear from.

    Is it bad for accessibility?

    Entity and percent encoding are invisible to assistive technology: the browser decodes them before anything reads the page. The CSS direction trick is the exception. Some screen readers read the reversed source order, and copy and paste gives the address backwards, so pair it with a contact form if you use it.

    What protects an address better than obfuscation?

    A contact form with server-side spam filtering keeps the address off the page entirely. Failing that, publish a role address such as hello@ that you can filter hard or replace, rather than a personal one. A good spam filter on the receiving side does more than any encoding on the sending side.

    Why does the scanner flag addresses that are already encoded?

    Because a harvester decodes them as easily as the scanner does. They are listed separately from plain ones so you can see which addresses you already tried to hide, and decide whether that is enough or whether the address should come off the page.

    Related tools

    Updated