Creating an email address link for a website means producing a mailto anchor in which every character of the visible address and the href target is written as a decimal numeric HTML character reference, so a browser decodes the reference into a clickable email link while a very basic scraper scanning source text for ordinary address patterns sees no literal address characters. The Email Address Obfuscator turns any validated public contact address into one such anchor entirely in your browser: it accepts an unquoted local part and a normalized domain, then emits the complete anchor element with no literal address characters anywhere in the output source. What you copy and paste is the whole obfuscated link, ready to drop into an HTML template where it continues to render as ordinary clickable text for visitors while keeping the raw source obscure to plaintext-matching bots. The technique is a form of source-level obfuscation rather than access control: the address is still discoverable to any crawler that decodes numeric entities, inspects the rendered DOM, or follows the mailto link when a visitor clicks.
Why Plain Email Addresses Get Scraped From Page Source
Contact addresses published as plain text on a website have always been a target for the most rudimentary harvesters. These are scripts that fetch a page, strip the HTML, and then run regular expressions looking for familiar shapes such as [email protected]. Because a public contact page is exactly where these patterns appear, a published address can end up on a marketing list within hours of going live.
Email obfuscation shifts that fight to a layer the simplest scrapers do not handle. Instead of leaving the raw characters in the markup, the published source contains decimal numeric character references such as j for the letter j. The browser unescapes those references before painting the page, so the visible link still reads as the real address and the mailto target still resolves correctly. A scraper that only matches plain text patterns against the raw response misses the address entirely. A scraper that actually decodes entities and walks the DOM, on the other hand, will still see it. The shift is from "easy to harvest" to "slightly harder to harvest," not from public to private.
What the Email Address Obfuscator Actually Outputs
The tool runs entirely in the browser and produces one single HTML element: an <a> tag whose visible text and href are written as numeric character references. The input is normalized first. Leading and trailing whitespace are trimmed, the local part keeps its original case and supported punctuation, and the domain is lowercased and run through the browser URL host parser so that an internationalized address such as jane@例え.jp is serialized to its ASCII-compatible form for stable reproduction across browsers.
Each code point in both the visible address and the mailto target becomes a decimal entity. The letter a, for instance, has the Unicode code point U+0061, which is 97 in decimal, so it renders in the source as a (see the WHATWG character references specification for the full reference syntax). The generated snippet contains the complete anchor, including the mailto: prefix in entity form, and the closing tag.
A practical constraint governs what counts as a usable input. The validator deliberately supports a narrow unquoted address shape rather than the full RFC 5322 grammar:
| Address shape | Accepted | Reason |
|---|---|---|
| [email protected] | Yes | Standard unquoted local part with a multi-label domain |
| [email protected] | Yes | Plus-addressing combined with a multi-label subdomain |
| jane@例え.jp | Yes | Internationalized domain, lowercased and ASCII-serialized |
| "jane doe"@example.com | No | Quoted local parts are outside the supported subset |
| jane@[192.0.2.1] | No | Domain literal with an IPv4 address is not accepted |
| jane@example | No | Single-label host is rejected |
| [email protected] | No | Leading dot in the local part fails validation |
| jane@@example.com | No | Repeated @ character fails validation |
The narrow contract exists so the result is reproducible across browsers and so the tool never reports success on an input it cannot faithfully reproduce. It does not test whether the mailbox exists, can receive mail, or is deliverable.
How to Create an Email Address Link Step by Step
This walkthrough uses the Email Address Obfuscator directly and assumes you have a public HTML template or a CMS that lets you edit raw HTML.
- Open the Email Address Obfuscator page in any modern browser. The tool runs locally and does not upload your address to a server.
- Enter the public contact address you want to publish in the input field. Use a plain unquoted form such as [email protected]. Plus-addressing and internationalized domains are accepted; quoted local parts, IP literals and single-label hosts are not.
- Generate the anchor. The output is one complete <a> element whose visible text and mailto: target are written as decimal numeric character references, with no literal address characters anywhere in the source.
- Copy the entire generated snippet to your clipboard. Make sure you copy the opening tag, the encoded text, the encoded href and the closing tag together; a partial copy will not render correctly.
- Paste the snippet into an HTML source context, such as a raw HTML block in your template, a static site file, or a CMS field that advertises HTML editing mode.
- Open the published page in a new browser window, click the rendered link once, and confirm that your mail client receives exactly the address you typed. Inspect the page source to confirm the entities are still in numeric form and have not been decoded by your CMS during publishing.
Paste Into HTML Source, Never Into a Rich-Text Field
The single most common reason an obfuscated anchor quietly fails is the editor the snippet is dropped into. A rich-text or WYSIWYG field does not store raw HTML; it parses the pasted string, decodes the entities into normal characters, and rewrites the markup in its own internal model. When you save and re-publish, the page source shows plain [email protected] again, and the obfuscation has been silently undone.
To avoid that, paste the snippet into a context that stores source verbatim. That includes static HTML files, raw HTML blocks inside a CMS, MDX or Markdown components that render through an HTML pass-through, and any "code" or "embed HTML" widget. If your CMS only exposes a rich-text editor, look for a "code view," a "custom HTML" block, or a shortcode that accepts raw markup. If no such option exists, the tool is not the right fit for that page.
While testing, also confirm that the editor does not double-escape the ampersand. If a content-management system replaces a with &#97;, visitors will see the literal entity text on the page rather than the letter a. Both failure modes are easy to miss in the editor preview because the preview often renders the link correctly even when the stored source is broken.
Verifying the Published Mailto and Inspecting the DOM
After publishing, treat the live page as the source of truth. Open it in a fresh browser session so caching and prior visits do not hide a regression. Read the link text aloud in your head and confirm it matches the intended address. Hover the link and read the status bar or tooltip that the browser surfaces for the href; both should agree.
Then open the page source and search for the raw address string. If you find it, the entities have been decoded somewhere in the publish pipeline and the obfuscation is no longer in effect. If you find only numeric character references inside the anchor, the source is still obfuscated and the technique is working as designed.
Click the link once to confirm the mail client receives the address intact. A mis-encoded character will surface here, because most mail clients reject malformed addresses or silently deliver to the wrong mailbox. This is also the moment to decide whether obfuscation is the right level of defense. A clickable mailto link necessarily exposes the address to anyone who copies it from the browser "copy link address" context menu, inspects the rendered DOM, or simply clicks and reads the new message window. For anything more sensitive than a generic contact address, the next section applies.
When Obfuscation Is Not Enough and What to Use Instead
Source obfuscation is a deliberate trade-off. It costs you nothing, adds no JavaScript dependency, and survives content security policies, but it also deters only the most basic harvesters. A modern crawler that decodes HTML entities, runs a headless browser, or follows rendered links will still recover the address. The tool itself documents this limitation next to the output rather than promising false confidence.
For contact addresses that actually need resistance to abuse, the standard answer is a server-side contact form with validation, rate limiting, captcha where appropriate, and proper spam filtering. The mailbox never appears in the page source at all, so there is nothing for a scraper to find. Disposable role-based addresses such as contact@, filtered through provider-side rules, offer an additional layer.
The Email Address Obfuscator fits when you specifically want a clickable, ordinary-looking email link on a public page, when the address is not secret, and when the goal is to take your contact details out of the easiest harvest lists. For everything else, choose a form.