An email address obfuscator is safe to use online only for lightweight source obscurity, not for guaranteed spam prevention or protecting a private address. The distinction matters on a public contact page. The Email Address Obfuscator performs processing in the browser and converts every code point in the visible address and mailto target into a decimal numeric HTML character reference. The generated source contains no literal address characters, so a very basic scraper that searches source for ordinary address patterns may miss it. That is the useful part, but it is also the limit. A browser decodes the references for display, so the address remains visible and clickable. Modern crawlers can parse HTML, decode numeric entities, inspect the DOM, or follow the mailto link. Visitors can recover the address by copying the link or inspecting the rendered page. The tool makes no promise to reduce spam. It suits a public contact address when modest source obscurity is enough; it does not suit a secret mailbox, credentials, a private alias, or any claim of access control. When abuse resistance matters, use a protected server-side contact form with validation, rate limiting, and appropriate spam controls, then verify the form on the delivered page.
Safety by publishing context
The safety verdict depends on what you publish and what you expect the encoding to stop. A public business contact and a private login identity should not be treated as equivalent.
| Use case | Practical verdict | Reason |
|---|---|---|
| Public contact address with lightweight source obscurity | Reasonable with limited expectations | It may evade basic plaintext matching, but the rendered address remains discoverable. |
| Secret mailbox, private alias, or credentials | Do not publish | Obfuscation is neither privacy protection nor access control. |
| High-volume spam prevention | Insufficient on its own | Modern crawlers can decode entities, inspect the DOM, and follow mailto links. |
| Clickable contact link for ordinary browsers | Suitable | Numeric references render as normal text while retaining a standard mailto anchor. |
For a public address, the method is reasonable when the goal is to avoid a simple plaintext pattern while preserving a normal click-to-email experience. It does not create a security boundary. If the goal is to stop determined harvesting or keep the mailbox unavailable, a protected server-side form is the better primary control.
How entity-only mailto anchors work
The tool emits every Unicode code point in the visible address and in the complete mailto prefix and address as a decimal numeric HTML character reference inside one anchor element. For example, the lowercase letter a is written as a in source and renders as a. Both the visible label and the href are encoded, so ordinary browsers still present a readable, clickable link.
Decimal character references are standard HTML parsing behavior, as described in the WHATWG HTML character-reference rules. Unlike a JavaScript-based injection, the generated anchor does not depend on scripts running and avoids adding script and content-security-policy failure points or extra moving pieces. It is still not encryption: the encoding is straightforward to reverse, and competent crawlers can decode it.
Processing stays in the browser, so the transformation itself occurs locally. That fact does not make the published address private. A visible contact address remains available to visitors and capable bots after the browser decodes it.
Generate and publish the anchor
Use this workflow for a public contact address and complete every verification step on the delivered page.
- Enter the public address. Open the Email Address Obfuscator and enter the address you intend to publish. The tool trims surrounding whitespace and validates the address against its practical, unquoted email format before generating the anchor.
- Generate and copy the complete element. Generate the numeric-entity HTML anchor locally, then copy the entire anchor element. Do not copy only the encoded visible text or rebuild the href by hand, because the complete output includes both the readable link and the encoded mailto target.
- Use an HTML source context. Paste the complete anchor into an HTML source template rather than a rich-text editor. A rich-text field may render the entities immediately or rewrite them before the page is saved.
- Open the delivered page and inspect it. Check the page source to confirm that numeric references remain in place and the literal address does not appear. Click the link once and confirm that the configured email application receives the intended address.
- Use stronger protection when necessary. If the page faces meaningful abuse or harvesting risk, use a protected contact form rather than presenting the obfuscated link as a security boundary.
Check the live page after publishing
Review the final public output rather than trusting the copied snippet. A content-management system, template, or publishing step can decode entities, double-escape them, or otherwise change the anchor after it leaves the tool.
- Inspect the delivered source: Confirm that the visible text and href still use numeric references and that the source contains no literal address characters. Check that the CMS did not decode or double-escape the entities.
- Check the rendered result: The page should display the intended address, not a sequence such as an entity code. The link should remain visibly clickable.
- Test the mailto link: Click it once and verify the destination in the email application that opens. A mailto link can launch whichever configured application the visitor uses.
If the CMS converts an encoded at sign back into a literal at sign, the source obfuscation is gone. If it rewrites the ampersands in the references, visitors may see entity text instead of the address. Always validate the real public page after a CMS or template change rather than relying on the copied snippet alone.
Input rules that affect completion
The validator is deliberately narrower than the full email standards. Its supported subset is designed for ordinary public website contact addresses, so some technically valid mailbox formats will be rejected.
| Input or behavior | Email Address Obfuscator rule |
|---|---|
| Address boundary | The address is trimmed before validation. |
| Local part | Requires a nonempty, unquoted local part. Leading, trailing, and consecutive dots are rejected. Original case and supported punctuation are preserved. |
| At sign | Requires exactly one at sign. |
| Domain shape | Requires a domain with multiple labels. Single-label hosts and IPv4 literals are rejected. |
| Whitespace and control characters | Addresses containing whitespace or control characters are rejected. |
| Domain case | The domain is lowercased and passed through the browser URL host parser. |
| Internationalized domains | The domain is serialized to its ASCII-compatible form so the output can be reproduced across browsers. |
| Complex mailbox syntax | Quoted local parts, comments, domain literals, and unusual legacy forms are not accepted. |
| Mailbox existence | The tool does not test whether the mailbox exists or can receive messages. |
A rejection can therefore reflect unsupported complex syntax rather than a nonexistent mailbox. Plus-addressing is covered by the tool's tests, subject to the same practical address-shape rules. The validator neither sends mail nor queries a server to confirm that a mailbox works.
Use stronger controls for higher-risk contacts
Meaningful abuse resistance requires controls around message handling. Use a protected server-side contact form with validation, rate limiting, and appropriate spam controls. This can keep the destination mailbox out of the published page markup while providing a controlled route for messages.
If a clickable public address remains important, a disposable role address can reduce the consequences of harvesting. Filtering rules and mailbox provider controls offer additional practical defenses. Treat any published role address as discoverable, because obfuscation does not change that fact.
Do not embed secret addresses, credentials, or private aliases. A mailto link can reveal its destination when a visitor clicks it, copies the link, or inspects the rendered DOM, and it can launch a configured email application. Use the obfuscator only when lightweight source obscurity is an acceptable goal.
For a deeper look, see How to Obfuscate an Email Address on a Website.