An email obfuscator is a small utility that rewrites a contact address into a form that basic page scrapers will skip over, while ordinary browsers still render and click it normally. The Email Address Obfuscator does this in one focused way: it converts a validated email address into a complete HTML anchor whose visible link text and mailto target are written entirely as decimal numeric character references. Each reference takes the standard HTML form of an ampersand, a hash sign, the decimal digits of a code point, and a trailing semicolon, and the browser decodes that sequence into the matching Unicode character when it paints the page. The literal characters of your address never appear in the source, so a scraper that only searches for plain address patterns like [email protected] finds nothing to copy. The output is plain static HTML. There is no JavaScript assembly, no image of an address, no alternate syntax to maintain, just one anchor tag the browser will render exactly as if you had typed the address in directly. That simplicity is the design, and it is also the limitation, because any tool that can read rendered HTML can decode the references back into the original address.
What the Tool Actually Produces
The whole output is one anchor element, copied as a single snippet. Inside that anchor, the visible text node holds the address with every code point replaced by its decimal numeric reference, and the href attribute value holds the string "mailto:" followed by the same address with every code point replaced by its decimal numeric reference. The conversion runs entirely in your browser. Nothing is uploaded, nothing is sent to a server, and no state is stored once you close the page.
The snippet you copy contains zero literal characters from your real address. If your address is [email protected], a viewer of the page source sees only a string of decimal references inside the href and the link text, while the browser decodes those references back to the address when it paints the page. That asymmetry is the entire effect. A bot that reads raw source for an address pattern finds nothing to harvest, while a visitor who clicks the link opens their mail client exactly as they would with any ordinary mailto anchor.
You can run the conversion locally with the Email Address Obfuscator tool, which produces that single anchor ready to paste into your HTML template. Because the technique is intentionally narrow, the tool is best understood as a publishing helper for one specific problem: keeping the literal characters of a public contact address out of the source you ship to a web server.
How Numeric Entity Encoding Works on a Single Anchor
Decimal numeric character references are part of the WHATWG HTML character reference specification. Each reference takes the form of an ampersand, a hash sign, the decimal digits of a Unicode code point, and a semicolon; the HTML parser turns that sequence into the matching character at render time. Every Unicode code point in the address, including letters in the local part, the at sign, digits, dots, and hyphens inside domain labels, receives the same treatment. A reference that encodes code point 97 produces the letter a and a reference for code point 64 produces the at sign, so an address that looks ordinary to a visitor is rebuilt from numeric pieces in the source.
Both the visible text and the mailto target go through this transformation. The result is an anchor that contains the address twice in encoded form, once where the visitor reads it and once inside the href that opens their mail client. Neither location holds a literal character from your real address. The encoder does not mix formats or invent alternate schemes: it emits one consistent decimal-only encoding because that form is the simplest to verify and the most predictable across browsers, and it avoids the failure modes that come with JavaScript-driven assembly.
For internationalized domain names, the encoder runs the domain through the browser URL host parser, which serializes it to its ASCII-compatible form. A domain like bücher.de is normalized to xn--bcher-kva.de before encoding, so the same input always produces the same anchor regardless of which browser you use to view the page and the output can be reproduced exactly on every visitor's machine.
Generate, Paste, and Verify in Three Steps
- Enter the public email address into the Email Address Obfuscator and click to generate the numeric-entity HTML anchor. The conversion runs locally in your browser, so no network call is required and no record of the address leaves the page.
- Copy the complete anchor into an HTML source context: a static HTML file, the source view of your content management system, or a code block that bypasses rich-text rewriting. A rich-text editor that auto-decodes entities will undo the obfuscation the moment you paste.
- Open the delivered page, inspect its source to confirm the entities survived publication, and click the link once to confirm your mail client receives the intended address. If real abuse resistance matters, pair the anchor with a protected server-side contact form rather than relying on source obscurity alone.
What the Validator Accepts and Rejects
The validator is deliberately narrower than the full email syntax described in RFC 5321 and RFC 5322. That narrow contract keeps the tool honest: it does not claim to validate every RFC-allowed form, it validates the practical contact-address use case the page is designed for. It also never checks whether the mailbox actually exists. It does not send mail, query DNS, or contact any server.
| Field | Rule | Accepted example | Rejected example |
|---|---|---|---|
| At-sign count | Exactly one | [email protected] | you@@example.com, youexample.com |
| Local part | Nonempty, original case kept, supported punctuation, no leading, trailing, or consecutive dots | info, jane.doe, news+tips | .jane, jane., jane..doe |
| Domain | Multiple labels, lowercased, no whitespace or control characters | example.com, sub.example.co.uk | example, 192.0.2.1, ex ample.com |
| Internationalized domain | Serialized to ASCII-compatible form via the browser URL host parser | bücher.de becomes xn--bcher-kva.de | Normalized rather than rejected |
Quoted local parts, comments, IP literals, and single-label hosts are not accepted, because this tool targets ordinary public website addresses rather than every mailbox syntax allowed by specialized systems. If your use case falls outside that scope, the encoder will tell you up front rather than produce a permissive but misleading validation. Treat the validator as a contract, not as a permissive blanket approval.
Where Source Obscurity Quietly Breaks Down
Two failure modes show up most often once an encoded anchor leaves the tool. The first is a rich-text editor or visual composer decoding the entities on paste. The CMS treats each numeric reference as the matching character and rewrites your source on the fly. The page then renders identically to a plain mailto link and the obfuscation is gone. The second failure mode is the CMS escaping the ampersand twice. It sees the leading ampersand and replaces it with another entity, producing literal entity text in the published page where visitors should see an address.
The fix is the same in both cases: open the live page, view its source, and confirm the entities survived publication. If your CMS strips them, paste the anchor into a raw HTML block, the code view of the editor, or a static file you control. Never trust a copied snippet alone, because the snippet is correct only as long as the publishing pipeline preserves it. The Email Obfuscator Cheat Sheet on output rules and CMS risks walks through specific CMS behaviors and the exact source patterns to look for when validating a published page, which complements the high-level picture laid out here.
When to Skip the Obfuscator Altogether
Source obscurity is one layer, and only a thin one. Pick a different approach when the address is internal, personal, or sensitive. Do not embed secret aliases, role mailboxes reserved for staff, or anything tied to credentials, because even encoded the address becomes visible to anyone who clicks the link, copies the link target, or inspects the rendered DOM. Pick a different approach when spam volume is already a problem, because the obfuscator does not promise to reduce spam and modern crawlers parse HTML, decode entities, and follow mailto targets as easily as a visitor would.
| Need | Encoded anchor | Server contact form |
|---|---|---|
| Clickable in ordinary browsers | Yes | No, form fields instead |
| Literal characters absent from page source | Yes | Not applicable |
| Hides address from a visitor who clicks | No | Yes |
| Server-side input validation and rate limiting | No | Yes |
| Resistant to modern HTML-parsing crawlers | No | Partial |
The obfuscator fits the case where you want a contact link on a public page, you understand the limitation next to the result, and you accept that any visitor who clicks the link will see the decoded address anyway. For meaningful abuse resistance, combine the anchor with a server-side contact form, a disposable role address you can rotate, mailbox provider filtering rules, and content security policies that prevent inline scripts from rewriting the document. The tool makes no promise that it will reduce spam and should never be treated as access control or privacy protection.
For a deeper look, see XML Sitemap Generator Cheat Sheet: Rules and Limits.