A numeric-entity mailto anchor presents a contact address as decimal HTML character references — for example the letter 'a' becomes a and the at-sign becomes @ — so the rendered page still shows and links the real email, while a basic scraper reading source text finds no plain address pattern to match. That single mechanism is the whole trick behind the Email Address Obfuscator, and understanding it is the difference between using the tool and accidentally undoing it. The tool runs entirely in the browser, trims the input, validates a practical unquoted address shape, and then emits every code point of both the visible text and the mailto: target as a decimal numeric reference inside a single anchor element. Because no literal address characters remain in the generated source, the output looks alien to a scraper that simply greps for the @ pattern. A competent crawler that parses HTML and decodes entities, however, will still see the address. The job of the rest of this article is to spell out the practical tips, the publishing traps that quietly destroy the encoding, and the limits you should respect from the start.
How Numeric Entity Encoding Actually Works
HTML supports two ways to write any character by code point: a named reference such as & or ©, and a numeric reference, which may be decimal or hexadecimal. The Email Address Obfuscator uses decimal because every browser in active use decodes a to the letter 'a' when it renders, while a plain text scraper that never executes the decoder sees only the entity string. Per the WHATWG HTML specification on character references, decimal numeric references take the form &# followed by one or more ASCII digits and a trailing semicolon — both the leading ampersand and the trailing semicolon are required for well-formed output.
A worked example makes the encoding concrete. The letter 'a' has Unicode code point U+0061, which equals 97 in decimal, so in HTML it is written as a. The letter 'm' is U+006D (decimal 109), written as m. The at-sign '@' is U+0040 (decimal 64), written as @. Replacing every character of [email protected] this way produces a string with no literal a, no literal @ and no literal e — precisely the property the tool relies on.
A crucial detail is that numeric references work in both the visible text of the anchor and the href value, which is why the tool encodes the full mailto: target the same way. The browser decodes the href back to mailto:[email protected] before handing it to the operating system's URL handler, so the link still opens the configured mail client with the correct address. The mechanism is ordinary HTML rather than JavaScript assembly, which avoids script-disabled failures, content-security-policy conflicts and extra moving parts.
Two consequences follow from that simplicity. First, the rendering is identical to plain text for every visitor, so there is no accessibility cost or layout change to worry about. Second, decoding is straightforward for anything that runs a real HTML parser, so do not let this technique encourage you to publish an address you would not otherwise publish.
Generate the Anchor Step by Step
- Open the Email Address Obfuscator and type the public contact address into the input field — use the actual address you intend to publish, not a private or credential-bearing alias.
- Generate the anchor locally in the browser. The output will be a single <a> element in which both the visible text and the mailto: target are entirely numeric entities, with no literal address characters anywhere in the source string.
- Copy the complete anchor verbatim. Do not trim the surrounding code or rewrite parts by hand; a partial encoding regression is one of the failure modes the tool explicitly tests against with exact-source assertions.
- Paste the anchor into the HTML source view of your page or template, not into a rich-text or WYSIWYG editor. Editors that render entities on save will silently turn @ back into @ before publishing.
- Save and publish the page, then load the live version in a normal browser and confirm the visible text reads as the address you expect.
- Right-click the link and choose "Copy email address" or view source — the raw HTML should still show numeric entities such as a for 'a' and @ for '@'. If you see literal letters or an actual @ symbol in the source, the encoding was undone somewhere in the pipeline.
- Click the link once to verify your mail client opens a new message addressed to the intended contact. If the client shows a garbled or missing address, treat that as a publish-time failure rather than a tool failure.
- For any address that truly needs abuse resistance, replace the obfuscated anchor with a server-side contact form that validates input, rate-limits submissions and applies spam filtering. Obfuscation is not a substitute for those controls.
Tips That Keep the Obfuscation Intact After Publish
Most loss-of-obfuscation incidents around this kind of tool come not from the encoding but from the publishing stack. The following tips target the failure modes that actually appear in real CMS, page-builder and static-site workflows.
Keep the address as intended. The validator preserves the case of the local part and lowercases the domain, so type the address exactly as visitors will write it ([email protected]) and let the tool normalize the domain to example.com. That keeps the rendered text identical to what visitors will type into their own mail client.
Treat the result as a snapshot, not a live component. The tool produces a string of HTML you must paste; if you ever change the address, regenerate the anchor from scratch rather than editing the entities by hand. A single unescaped ampersand or a stray visible character breaks the pattern the scraper would otherwise miss.
Stay in source view while editing. WYSIWYG editors, Markdown composers with HTML rendering and many visual page builders decode entities back into characters on save, instantly destroying the obfuscation. Switch the field to a Code block, an HTML widget or a raw-HTML template before pasting. The Email Obfuscator Explained guide walks through why this matters at the markup layer rather than at preview time.
Watch for double-escaping. A second layer of entity encoding is just as fatal as a decoded one — if a sanitizer wraps your & in another & before storing the post, visitors see literal entity text instead of the address in the rendered page. Always verify the live, public output rather than trusting the editor preview.
Internationalize with care. If the domain contains non-ASCII letters, the tool lowercases and serializes it to its ASCII-compatible (punycode) form before encoding. That means inputting héllo@exämple.de produces an anchor whose href is a stable, browser-independent string — a useful property if multiple readers and machines consume the page.
Common Mistakes When Obfuscating an Email Address
The mistake list for this technique is short but repeated. Each item below is a real failure mode and a concrete fix.
Mistake 1: Treating obfuscation as security. The most common error is expecting the anchor to keep an address private. It does not — it only makes the source harder to read than a plain literal. Anyone who right-clicks the link or inspects the DOM sees the address; a capable crawler will decode the entities in the same browser pipeline that humans use. If the address must stay secret, do not publish it at all.
Mistake 2: Embedding private aliases or credentials. Because the address will be recoverable, never put a private alias, an internal staff alias or anything resembling a credential into the obfuscated anchor. Use a role address that is already public (info@, support@, press@) and treat any submission to it as untrusted input.
Mistake 3: Pasting into a rich-text editor. Editors that render entities on save decode @ back to @, after which the page ships a literal address. The fix is to paste only into a code-context field and to validate the published source afterwards.
Mistake 4: Trusting the preview pane. Many editors preview the rendered output, not the raw HTML, so a successful preview gives no evidence that the entities survived. Always view source on the live URL.
Mistake 5: Skipping the validator. The validator accepts a narrow unquoted shape. If your real mailbox uses a quoted local part, a domain literal or an IPv4 host, the tool will reject it. Trying to "force" the encoding by hand typically produces incomplete output — the tests in the tool assert exact expected entity strings precisely so a partial encoding cannot pass.
Mistake 6: Hiding only the rendered mailto:. Some authors obfuscate the visible text and forget the href. With nothing in the href, the link does not open a mail client and the address is effectively unusable. The tool always emits both.
Mistake 7: Forgetting that visitors can copy the rendered address. They can click it, copy the link target, copy the visible text, or paste the rendered DOM. The realistic target of obfuscation is automated matching in source, not human copying.
Limits That Are Worth Naming Out Loud
The Email Address Obfuscator explicitly states its limitation next to the result, because an obfuscator should not create false confidence. Three limits are worth internalizing before you adopt it for a real page.
First, modern crawlers parse HTML, decode numeric character references, inspect the rendered DOM and follow mailto links. They see the address the same way a visitor does. There is no reliable way to publish a clickable address and keep it hidden from a determined bot, and the tool makes no promise that it will reduce spam in any quantitative sense. Treat any observed reduction in unsolicited mail as anecdotal and look at your actual abuse channels separately.
Second, mailto links can launch the configured mail application on the visitor's machine. That application may store the address in its history, in autocomplete or in a synced account. Visitors who copy the link or the rendered text can also forward it elsewhere. This is true of every visible mailto link, obfuscated or not, and is why the tool warns against embedding secret addresses.
Third, the validator's narrow contract rejects some syntactically valid mailbox forms — quoted local parts, IPv4 literals, single-label hosts — because the page is targeted at ordinary public website addresses, not every legacy mailbox shape. That narrowness is deliberate: a permissive but misleading validator would be worse than a strict one. For practical public contact addresses, the validator is plenty wide. The Email Obfuscator Safe: Honest Limits and a Safer Setup guide covers the rest of the safer-setup checklist.
Validator Acceptance at a Glance
The table below summarizes how the tool treats representative inputs. Use it to predict whether your address will pass before you spend time adjusting the form.
| Input | Result | Reason |
|---|---|---|
| [email protected] | Accepted | Standard unquoted public address |
| [email protected] | Accepted | Plus-addressing is supported |
| [email protected] | Accepted | Domain is normalized to lowercase |
| héllo@exämple.de | Accepted | Domain is serialized to its ASCII-compatible form |
| [email protected] | Rejected | Leading dot in the local part is not allowed |
| [email protected] | Rejected | Consecutive dots in the local part are not allowed |
| user@localhost | Rejected | Single-label host is not supported |
| user@[192.0.2.1] | Rejected | IPv4 literal is not supported |
| "quoted"@example.com | Rejected | Quoted local part is outside the practical subset |
| user@exa mple.com | Rejected | Whitespace anywhere in the address is not allowed |
Treat the right-hand column as the rule the validator actually enforces, not as commentary on which mailbox forms are technically deliverable — the tool does not test delivery.
Putting it together, the most useful email obfuscator habits are simple: pick a public role address you are already willing to publish, generate the anchor with the Email Address Obfuscator, paste it into a code-context HTML field, and view the live published source to confirm the entities survived. Everything else — the rich-text editor you avoided, the double-escape you caught, the preview you did not trust, the contact form you reached for instead — is what separates a working obfuscation from an illusion of one.