An info@ email address is the most recognizable general-contact alias used on public websites, typically written as [email protected] for sales, support and general enquiries. To publish that address on a page while reducing its exposure to plain-text harvesters, you can encode the full anchor (the visible text and the mailto: target) using decimal numeric HTML character references such as i for "i" and n for "n". A browser still decodes those references and displays the address exactly as written, but a basic scraper that hunts for raw address patterns inside the HTML source will find nothing recognizable to copy. The obfuscation lives in the page source — the rendered page, the click target, and the recipient address remain identical to a normal mailto link. Working with this approach means accepting that any visitor, or any modern crawler, can still resolve the address after the page renders, so the technique is suited to lightweight public-contact display rather than access control. The remainder of this article walks through the exact steps, the source-level verification, and the limits to know before relying on it.
What an info@ Email Address Is Used For
info@ belongs to a small set of standard role-based mailboxes — info@, contact@, sales@, support@ — that organizations route to whichever person or shared inbox should field general enquiries. Picking info@ signals that a visitor does not need a pick a specific department, and that any reply can be triaged later. The convention is older than consumer webmail and survives because it is memorable and because mail servers treat the local part before the @ as a normal identifier that can be forwarded, aliased, or grouped into a shared mailbox without configuration changes for the sender.
Two practical realities follow. First, the prefix is widely known, which means a scraper does not need to guess it — it can search for "info@" near a domain and collect candidates cheaply. Second, the address is meant to be public, so there is no expectation of secrecy; the question is purely how the address is exposed on a page and how much friction that exposure adds to harvesting. For a site owner the trade-off is to keep the address clickable and human-readable for genuine visitors while denying trivial plaintext search inside the HTML source, which is exactly what numeric entity encoding is built for. If you are choosing between role addresses for a small site, the broader question of which prefix fits which use case is covered in a guide on creating a special email address for public sites.
How Source-Level Obfuscation Works
A normal clickable email link on a webpage is built from two pieces — the visible text between <a> and </a>, and the value of the href attribute, which begins mailto: followed by the address. Every character in both pieces is a literal character stored in the HTML file. A scraper that downloads the file and runs a regular expression such as [\w.+-]+@[\w-]+\.[\w.-]+ will extract the address in milliseconds.
Numeric entity encoding rewrites every character so that the file no longer contains the address in plain form. Lowercase a becomes a, @ becomes @, and so on, one decimal reference per code point. When the browser renders the file it follows the references, assembles the address and displays it normally. When a scraper reads the file as text and runs that same regex, the pattern finds nothing — the bytes between the tags are all &, #, digits and ;, not the letters of an email address. The mechanism is documented in the WHATWG HTML standard as decimal numeric character references at html.spec.whatwg.org/multipage/named-characters.html#character-references, and every modern browser decodes those references the same way.
Generating the info@ Anchor Step by Step
Use the Email Address Obfuscator with a contact address such as [email protected].
- Enter the full public address and generate the anchor locally. The tool validates the local part, lowercases the domain, serializes internationalized domains to their ASCII-compatible form and emits a single anchor element whose every code point — visible text, mailto: prefix and address — is a decimal numeric reference.
- Copy the complete anchor into an HTML source view. Paste it into a template or directly into your page's HTML. Never paste it into a rich-text editor or the visual mode of a content management system, because those surfaces frequently decode entities on save and wipe the obfuscation.
- Open the published page, inspect its source and test the mailto link. Confirm the entities are still present in the file, then click the rendered link once to verify your mail client receives exactly the address you entered. If the source shows literal letters or shows double-escaped references such as &#97;, the obfuscation is gone and the link has fallen back to a plain mailto.
Step three is the only step that proves the work succeeded. Skipping source inspection is the most common reason teams publish what they think is an obfuscated address and discover later that the page contains the literal string after all.
Verifying the Published info@ Anchor
Verification has three checks, and each one catches a different failure mode.
First, look at the page source. The anchor should contain &# sequences throughout. If you see plain letters, or you see &# (the ampersand itself escaped to &), the CMS has rewritten the markup and visitors will either see the address as raw HTML entities or the obfuscation will be gone entirely.
Second, click the rendered link from a fresh browser session. Your mail client should open with the address exactly as you typed it, with the same casing in the local part and the same lowercased domain. If the client offers a different address, the entity sequence had a code-point error and the output needs to be regenerated.
Third, copy the link from the rendered page (right-click, copy link address) and paste it into a text editor. Most browsers expose the resolved mailto: value, and any address visible there is also visible to a competent crawler that runs JavaScript against the same page. This is a useful sanity check, not a vulnerability — any visitor can do the same thing.
Obfuscation vs. Contact Form: When Each Is Enough
Source-level encoding and server-side contact forms solve overlapping but different problems. The table below compares their capabilities directionally; the exact guarantee each one provides depends on your server configuration, your visitor profile, and your publishing pipeline, so read the cells as capabilities rather than measured spam rates.
| Need | info@ with numeric entity encoding | Server-side contact form |
|---|---|---|
| Visible, clickable contact for any visitor | Yes — renders normally | Replaced by form fields |
| Blocks plaintext regex harvesters | Yes — source contains no letter pattern | Not applicable — no address is published |
| Blocks modern crawlers that decode entities or follow mailto links | No | Mostly — addresses are not exposed at all |
| Survives scripts disabled, CSP rules, JavaScript errors | Yes — pure HTML | Yes — pure HTML form |
| Provides rate limiting, captcha and input validation | No | Yes — enforced server side |
| Routes messages to a role inbox or shared mailbox | Yes — depends on your mail setup | Yes — backend can route or alias freely |
| Suitable for secret addresses, credentials or private aliases | No | Closer, but the destination server still needs hardening |
Read the comparison qualitatively: source obfuscation adds a thin veil against the cheapest scanners, while a contact form adds operational defenses that scale with your traffic. For meaningful abuse resistance, combine the form with rate limiting, disposable role addresses and mailbox provider controls rather than relying on either alone.
Common Limits and Pitfalls
Numeric entity encoding has three properties worth stating plainly.
It is a source-level technique. Anything that parses the HTML — a screen reader, a browser extension, a well-written crawler, a clipboard copy of the rendered text — sees the resolved address and can act on it. There is no HTML-only encoding that hides the address from a visitor who can see the page.
It survives only if your publishing pipeline preserves entities. WYSIWYG editors, markdown processors that escape ampersands, server-side templates that auto-escape, and some accessibility tooling silently rewrite a back to a. After every CMS, plugin or framework update, re-inspect the source.
It is not access control. Do not rely on it for secret addresses, for credentials, for internal aliases, or for any mailbox whose compromise would be costly. For those, use a contact form with server-side validation and rate limiting, and never publish the address in any form.
When info@ Doesn't Fit the Validator
The Email Address Obfuscator accepts a narrow, practical address shape: a nonempty unquoted local part, exactly one @, a domain with multiple labels, and no whitespace or control characters. Leading, trailing or consecutive dots in the local part are rejected, and quoted local parts, comments, domain literals and IPv4 mailbox forms are not supported.
If your role address uses plus-addressing for routing — for example [email protected] — the tool accepts it because the local part contains supported punctuation and no surrounding whitespace. If your hosting provider gives you an address with a single-label domain or an IP-based host, the validator will reject it because the tool is intended for ordinary public website addresses, not every mailbox syntax allowed by specialized systems. These rules trade breadth of syntax for clarity about what the output represents; an unusual form that matters to your organization should be set up outside the tool rather than forced through a validator that would misrepresent it.