An email address encoder turns a public contact address into an HTML anchor whose visible text and mailto target are written entirely as decimal numeric HTML character references, so the page source contains no literal @ or domain characters yet visitors still see a clickable address. The Email Address Obfuscator performs that encoding locally in the browser: every Unicode code point in both the displayed text and the href becomes a form such as a for a lowercase a, the mailto: prefix is preserved as a chain of decimal entities, and the resulting anchor is delivered without any literal address characters anywhere in its source. Because the tool never sends the address to a remote server, the encoded result is reproducible on demand, audit-friendly for code review, and safe to publish for ordinary public website addresses. The output is still a working mailto link that opens the visitor's configured email client when clicked, copied or saved, which keeps the page useful for real readers while making the source harder for very basic plaintext scrapers to match. The encoding is plain static HTML rather than JavaScript-injected markup, so visitors who disable scripts still see a working link and content-security-policy headers are not stressed by inline event handlers.
What the Encoder Writes Into Your HTML
An encoder does not just swap the @ symbol for an image or scramble the visible letters. It rewrites the entire anchor, both the human-readable text between the opening and closing tags and the href value that browsers resolve when a visitor clicks, into a sequence of decimal numeric character references defined in the WHATWG HTML character references specification. The result is ordinary, static HTML. A browser parses the entities during rendering and shows the original characters; a visitor sees exactly the address they would have seen with a plain anchor. The difference shows up only when you view source: there is no [email protected] string for a naive scraper to grep.
The shape of the output stays consistent across inputs. One <a> element wraps the encoded visible text, and one href attribute wraps the encoded mailto: prefix followed by the encoded address. The local part keeps its original case and supported punctuation, the domain is lowercased before encoding, and internationalized domains are serialized to their ASCII-compatible form so the same output reproduces across browsers. Because every code point is encoded, even dots, hyphens, plus signs, slashes and the @ character travel through the entity layer rather than appearing as themselves. The link is still clickable, still resolves to a mailto URL, and still triggers the visitor's email handler with the correct address.
Generate and Paste the Entity-Only Anchor
The full workflow for using the encoder on a public contact page is short, but each step matters. Use the Email Address Obfuscator for the encoding step, then move the result into a controlled HTML template rather than a content editor that may rewrite entities on save.
- Enter the public contact address and generate the anchor locally. Type the address into the input field, submit, and let the tool produce the complete encoded anchor in your browser. The address never leaves the page; the validator checks the shape and the encoder emits the entities in one pass.
- Copy the complete anchor into an HTML source template, not a rich-text editor. Paste the snippet into the HTML view of your CMS, a static template file, or any context that stores raw markup. Avoid pasting it into a WYSIWYG editor that might re-encode the ampersand in a or strip entities altogether.
- Open the delivered page, inspect source, click the link once, and confirm a contact form is present for sensitive addresses. After publishing, view source on the live page: literal address characters should be absent, and the entities should still read a rather than the decoded a. Click the link to confirm the mail client receives the intended address. Where the address actually receives abuse-prone traffic, add a server-side contact form with validation and rate limiting so the encoded anchor is one layer rather than the only layer.
How the Validator Shapes the Accepted Address
The encoder does not try to match every mailbox syntax allowed by specialized mail systems. It accepts a practical, unquoted local part followed by a public domain made of multiple labels, with no whitespace or control characters and no leading, trailing or consecutive dots in the local part. Internationalized domains are accepted and converted to their ASCII-compatible form; IPv4 literals, single-label hosts, quoted local parts, comments and domain literals are rejected because the encoder is aimed at ordinary public website addresses, not at every specialized form a mail server might accept on a private network. The local part keeps its original case and supported punctuation. The validator is intentionally narrower than the full email standard: a permissive parser would either let through inputs the tool cannot safely encode, or accept addresses that look correct yet never reach a real inbox.
| Input shape | Accepted | Reason |
|---|---|---|
| [email protected] | Yes | Single unquoted local part, multi-label domain, no whitespace. |
| [email protected] | Yes | Plus-addressing and dots in the local part are supported. |
| [email protected] | Yes | Internationalized domain is normalized to its ASCII-compatible form. |
| [email protected] | No | IPv4 literals are rejected for ordinary public website addresses. |
| user@localhost | No | Single-label hosts are rejected. |
| [email protected] | No | Leading, trailing or consecutive dots in the local part are rejected. |
| "quoted"@domain.com | No | Quoted local parts are outside the practical unquoted subset. |
| missing-at-symbol.com | No | Exactly one @ is required. |
The validator does not test whether the mailbox actually exists, accepts mail, or belongs to a particular person. A shape-valid address can still bounce or forward to nowhere, so the encoder never implies deliverability.
Why Numeric-Entity Obfuscation Is Not Spam Protection
The technique that the encoder uses is obfuscation, not security. Numeric character references are a rendering feature of HTML; any program that can parse HTML, which includes essentially every modern crawler, can decode them, walk the DOM, follow the mailto target, or read the link the visitor would have clicked. A very basic scraper that searches source text only for ordinary address patterns, the kind that runs before any HTML is parsed, may miss the encoded form. Beyond that baseline, the protection disappears. Modern crawlers parse HTML, decode entities, inspect the rendered DOM, and even resolve mailto links into the address they would deliver to. A publicly rendered address remains discoverable to visitors and to capable bots regardless of how it is encoded.
Mailto links have additional surfaces. Clicking the link in many browsers reveals the address through hover preview, context menus or the email client's compose window. Copying the link, saving it, or inspecting the rendered DOM in browser dev tools exposes the address as well. JavaScript-dependent address injection has its own failures: it can fail when scripts are disabled, conflict with content security policy, and add moving pieces that a static entity-only anchor avoids. Numeric references keep the result as ordinary HTML, but that simplicity also makes decoding straightforward for any program that bothers to try. The encoder states this limitation next to its output because an email obfuscator should not create false confidence about how much spam it will actually prevent.
Where to Paste the Anchor So the Encoding Survives
The whole point of encoding disappears if the publishing pipeline decodes the entities back to plain text. Several content systems rewrite entities on save: a WYSIWYG editor may resolve a to a before the page is rendered, a CMS sanitizer may normalize ampersand sequences, or a server-side filter may flag the encoded mailto as suspicious and strip the href value. The encoded anchor has to land in a context that stores raw HTML and serves it back unchanged.
The safest destinations are static HTML files, theme template files in plain-text mode, custom HTML blocks that disable auto-correction, and code-injection fields that explicitly preserve entities. The risky destinations are rich-text editors, visual page builders with built-in sanitizers, blog editors that auto-link email patterns, and any workflow that ships the snippet through a Markdown processor with link-shortening rules. After publishing, view source on the live page and confirm two things: literal [email protected] characters are absent from both the visible text and the href, and the entities still read a rather than the decoded a. If your CMS has decoded the entities for you, the obfuscation is gone; if it has double-escaped them into &#97;, visitors may see the entity text instead of the address. Always validate the real public output rather than relying on the copied snippet alone.
For a more thorough walk-through of building a working mailto link before applying the encoder, the step-by-step guide on creating an email address link covers the underlying markup conventions the obfuscator preserves.
Pair the Encoding With a Server-Side Contact Form for Real Resistance
The encoded anchor is one layer of source obscurity. It keeps the address clickable for visitors, costs nothing to render, and deters the most trivial address collectors. It does not on its own reduce abuse for an address that is already being targeted. For meaningful resistance, combine the encoded anchor with measures that operate where the encoding cannot reach: a server-side contact form that validates input, applies rate limiting, and uses a captcha or equivalent challenge for suspicious submissions; a disposable role address such as contact@ or info@ that you can rotate when it appears on a list; mailbox-provider filtering rules that quarantine obvious junk; and reputation or response-rate controls on the receiving inbox. The encoder's role in that stack is to keep the address out of the very simplest greps while a stronger mechanism handles the heavier traffic.
| Approach | What it actually does | What it does not do |
|---|---|---|
| Entity-only anchor (this tool) | Removes literal address characters from the rendered HTML source. Survives visitors who disable scripts. | Does not stop modern crawlers, mailto link inspection, or motivated scrapers. |
| Server-side contact form | Hides the destination address entirely, applies validation and rate limits, filters submissions. | Does not, by itself, give visitors a clickable mailto link. |
| JavaScript-injected address | Keeps the address out of the static source until scripts run. | Breaks for visitors with scripts disabled, conflicts with strict CSP, and adds moving pieces. |
| Role address with provider filtering | Replaces the personal address with a public alias and filters submissions on the receiving side. | Does not address scraping of the visible page source. |
For most public websites, the practical stack is an encoded anchor for the lightweight contact link plus a server-side form for serious inbound traffic. The encoder fits naturally as the visible-link half of that pair, doing what it actually promises without overselling what it cannot guarantee.