The Email Address Obfuscator produces a single HTML anchor whose visible text and mailto target are written entirely as decimal numeric HTML character references, leaving no literal address characters in the rendered source. Every code point of the local part, the @ sign, and the normalized domain becomes a reference such as a for a lowercase a, which a browser decodes when displaying the page and which a basic plaintext scraper may overlook because the source no longer contains a recognizable address pattern. The output is one anchor element, copied as-is into a controlled HTML source context rather than a rich-text field that might rewrite entities on save. Processing happens entirely in the browser, nothing is uploaded, no server checks the mailbox, and the generated source contains only entity references and the mailto: prefix. This cheat sheet documents the exact output shape, the validation rules that decide which addresses the tool will accept, the limits that determine whether obfuscation is appropriate for your page, and the CMS and editor rewrites that can quietly undo the obfuscation between the moment you paste and the moment a visitor loads the page.
Output Anatomy of the Generated Anchor
The result of one run is a single anchor element. Inside the href, the literal string mailto: is followed by the address, with each code point of the address written as a decimal numeric character reference. Inside the visible text, the same rule applies so what the visitor sees is the real address, not the entities themselves. If the address is [email protected], the link target looks like mailto:info@example.com and the visible text resolves to the same string once the browser decodes it. No JavaScript is required to assemble the address at runtime, no document.write call reconstructs the mailto at click time, and no CSS pseudo-element carries the address out of the source. The single anchor is the entire deliverable, and that simplicity is what lets it work in browsers with scripts disabled and inside content security policies that forbid inline scripts. The decimal numeric character reference format itself is the same one the HTML living standard documents for character references in general markup, which is why every conformant browser decodes it identically without any custom parsing.
For an address that contains a plus sign such as [email protected], the plus is encoded as + and the rest follows the same rule, so the resulting anchor behaves identically to one written with literal characters once a browser decodes the page. The anchor stays clickable, opens the configured mail client with the correct recipient, and survives copy and paste from the rendered page because the visible text is the actual address.
Validation Rules: Accepted and Rejected Forms
The tool validates a single shape and rejects everything outside that shape on purpose. A permissive validator that accepted every RFC 5322 form would mislead users about what is supported, so the contract is narrow and explicit. The local part must be non-empty, must not start or end with a dot, must not contain consecutive dots, and must not contain whitespace or control characters. The domain must contain more than one label, must contain no whitespace, and is lowercased and passed through the browser URL host parser. Internationalized domains are serialized to their ASCII-compatible form so the output reproduces identically across browsers. IPv4 literals and single-label hosts are rejected because this page is intended for ordinary public website addresses, not every mailbox syntax that specialized systems allow.
| Address Form | Status | Reason |
|---|---|---|
| [email protected] | Accepted | Standard unquoted local, multi-label domain |
| [email protected] | Accepted | Plus-addressing supported in the local part |
| [email protected] | Accepted | Local case preserved, domain lowercased |
| [email protected] | Accepted | Multi-label domain with a subdomain |
| info@bücher.example | Accepted | Internationalized domain serialized to ASCII-compatible form |
| [email protected] | Rejected | Leading dot in the local part |
| [email protected] | Rejected | Consecutive dots in the local part |
| info@@example.com | Rejected | More than one @ character |
| info@example | Rejected | Single-label domain |
| info@[192.0.2.1] | Rejected | IPv4 literal not supported |
| "quoted"@example.com | Rejected | Quoted local part not supported |
| info@ example.com | Rejected | Whitespace anywhere in the address |
That narrowness is the contract. If your address fails the validator, the fix is usually to use an unquoted form, normalize the domain casing, or drop a quoted-local syntax that was never meant for a public contact link anyway. The tool does not test whether the mailbox exists or can receive messages; it only checks that the shape fits an ordinary public contact address. Rejection is not a hint that the address is invalid in some absolute sense; it is a signal that the syntax falls outside the practical subset this page is built to serve.
How to Use the Tool Step by Step
- Open the Email Address Obfuscator and enter the public contact address you want to publish. Use the form you would publish as-is on a contact page, not an internal alias, a role address you do not want exposed, or anything that resembles a credential.
- Click the generate action. The tool trims whitespace, validates the narrow unquoted shape, lowercases the domain, runs the domain through the browser URL host parser, and emits the anchor element locally in your browser. No request leaves the page.
- Copy the complete anchor element. Select from the opening <a through the closing </a> so the href and the visible text move together. Do not paste it into a rich-text editor that may auto-format or sanitize HTML, and do not paste it into a WYSIWYG field that converts characters as you type.
- Paste the anchor into an HTML source template, a static-file editor, or a CMS field that accepts raw HTML. The page should reach a live URL only after this step.
- Open the delivered page in a browser, confirm the visible text matches the address you entered, and click the link once to confirm the mail client receives the intended recipient.
- View the page source of the delivered page and confirm the entities are still entities. If a CMS has rewritten a back to a, the obfuscation is gone. If it has rewritten & inside the entities into another reference, visitors may see entity text such as i instead of the letter it represents.
The Hard Limits That Matter
The tool states a single limitation next to the result, and the limit is the same one every honest email obfuscator shares: obfuscation is not security. The cheat sheet version of that fact is a small reference table that lists what the output does and does not accomplish, because an email obfuscator should not create false confidence.
| Capability | Yes or No |
|---|---|
| Stops basic plaintext-pattern scrapers | Possibly, depends on the scraper |
| Stops crawlers that parse HTML and decode entities | No |
| Stops crawlers that follow mailto links | No |
| Stops crawlers that render the page and read the DOM | No |
| Reduces spam at the mailbox | Not guaranteed |
| Acts as access control or privacy protection | No |
| Requires server processing | No, browser-only |
| Survives in every HTML source context | No, some CMS fields rewrite entities |
| Verifies that the mailbox exists | No |
Every modern crawler the search results or social previews care about parses HTML, decodes numeric character references, and inspects the rendered DOM. Visitors who click the link, copy the link, or hover to read the target also see the address. Anything you would not want a careful visitor or a capable bot to know should not be the string that goes through this tool, and visitors who launch the link will see a configured mail application open with the address filled in. For a deeper look at the entity-only anchor format itself, the Email Address Encoder guide walks through the same anchor shape from the encoding angle.
CMS and Editor Pitfalls That Strip Entities
The most common failure mode is not in the tool; it is in the publishing step. Editors and content management systems routinely normalize the HTML they receive, and that normalization is exactly the kind of operation that undoes obfuscation. A WYSIWYG editor that round-trips content through a DOM parser will replace a with the literal character a on save, because to the parser the entity and the character are equivalent. The page may render correctly but the source no longer matches the obfuscated snippet you copied, and the address is back in plaintext in the published HTML.
A field that sanitizes input may reject the entities, escape the ampersand into a different reference such as &, or strip the mailto: prefix. In that case the obfuscation survives in the markup but the link itself no longer opens a mail client, and visitors see either a broken link or visible entity text such as i where the letter should appear. The defense is verification. After publishing, view the live page source in a browser, search for the literal address characters you expected to encode, and click the link. If the literal characters are present, the CMS has decoded the entities. If the link is broken or the visible text shows entity codes, the sanitizer has rewritten too aggressively. Either outcome means the obfuscation did not survive publishing, and the fix is in the publishing step rather than in the tool.
Obfuscation vs Real Defenses
The obfuscator is the right pick when the page already needs a clickable contact address, the address is one you would publish in plaintext anyway, and the goal is to add a thin layer of friction against simple scrapers without adding a server dependency. It is the wrong pick when the address is private, when meaningful spam reduction is required, or when access control matters. Mailto links can expose addresses when visitors click, copy the link, or inspect the rendered DOM, and they can launch a configured email application, so the input should never be a secret address, a credential, or a private alias.
For meaningful defenses, the practical stack is a server-side contact form with input validation, rate limiting, and the spam controls your platform offers; a role address you can rotate if it starts receiving abuse; and mailbox provider filters that catch what slips through. The obfuscator sits in front of those, not in place of them, and an email obfuscator that claims otherwise should not be trusted. That separation is why the tool prints the limitation next to the result rather than burying it in documentation. The cheat sheet version is the same: use the obfuscator for source-level friction on a public contact address, and reach for a contact form the moment the goal moves from inconvenience to protection.
Verification Checklist Before You Publish
The fastest way to know whether the obfuscation actually shipped is a short, repeatable check against the live URL. Open the published page in a browser, then view its source and search for the literal characters of your address; if the search finds them, the entities were decoded on save and the obfuscation is gone. Click the link once to confirm the mail client opens with the correct recipient populated; a missing or wrong address is the most visible symptom of a sanitizer that over-escaped the ampersand or stripped the mailto prefix. Hover over the link and read the target your browser shows; the visible anchor and the mailto target should both decode to the same address you entered. Finally, re-copy the address from the rendered page (not the source) and use it once; if the round-trip matches what you originally typed, the visitor experience is correct regardless of what the underlying source looks like. None of these checks require special tooling, and together they catch every CMS behavior that would silently undo the work the tool just did for you.