An email obfuscator API alternative is a browser-local tool that encodes a public contact address as decimal numeric HTML character references inside a mailto anchor, so the source contains no literal address characters and no server call is required to produce or serve it. The address you want to publish never leaves the page, never reaches a third-party endpoint, and never depends on a JavaScript SDK fetching it at runtime. The output is static HTML that a browser renders normally while a very basic plaintext scraper sees only entity references instead of an address-shaped string. The technique is described in the WHATWG HTML specification, where any code point can be written as a numeric character reference that the browser decodes during rendering. Used inside a mailto anchor, this produces a clickable link whose visible text and href are both composed entirely of references, with no literal @ or domain characters left in the source.
What "API Alternative" Means for Email Obfuscation
Many published email obfuscation services require a developer account, an API key, a JavaScript SDK that fetches the address at runtime, or a server endpoint that rewrites the page. The "API alternative" framing matters when you want the same protection surface, meaning a rendered address that is not visible as plain text in source, without sending the address through a third-party system, without provisioning credentials, and without introducing a network request that can fail, log data, or be blocked by a content security policy.
An email obfuscator API alternative in the browser-local sense is a tool that accepts one address, encodes every character as a decimal numeric HTML entity, and returns an anchor whose visible text and mailto target are both composed entirely of those references. The address never leaves the page, never reaches a server, and the result is static HTML that can be reviewed, copied, and committed to a template.
This pattern is useful when you maintain a static site, host under a strict CSP that disallows third-party scripts, run a CI pipeline that builds HTML without network access, or simply prefer that the public contact address remain on infrastructure you control. The anchor is portable across hosts because it is plain HTML; there is no SDK version to track and no client library to load.
How Entity-Only Encoding Works in the Browser
The encoding technique is grounded in the WHATWG HTML character references specification, which defines numeric character references such as a for the letter a. A browser decodes those references during rendering and displays the original character. A naïve scraper that searches raw source text for the literal pattern [email protected] will not find a match when the source contains only entities.
The tool applies the encoding uniformly. Both the visible anchor text and the mailto href are constructed from decimal references for every Unicode code point, and the generated source contains no literal address characters. The address is trimmed, validated, lowercased on the domain side while keeping the local part's original case, and internationalized domains are serialized to ASCII-compatible form so the output reproduces identically across browsers.
Processing stays in the browser. There is no POST request, no API call, no rate-limited endpoint, and no secret key to manage. The anchor you copy is the final HTML, ready to paste into a template. Numeric references also keep the result as ordinary HTML that any browser renders without executing code, which avoids the script-disabled and CSP-conflict problems that come with JavaScript-based address reassembly.
Generate an Entity-Only Mailto Anchor in Your Browser
- Open the Email Address Obfuscator in a browser and enter the public contact address into the input field. The validator requires a practical unquoted form: a nonempty local part, one @, a domain with multiple labels, no whitespace, and no leading, trailing, or consecutive dots in the local part.
- Run the generate action. The tool trims the input, validates the shape, lowercases the domain, runs the host through the browser URL host parser, and emits one anchor whose visible text and mailto target are written entirely as decimal numeric character references.
- Copy the complete anchor exactly as it appears. Do not paste it into a rich-text editor such as a CMS WYSIWYG field, a word processor, or an email composer. Those environments decode entities on paste, rewrite & to &, or replace a with the letter a, which destroys the obfuscation before the page is published.
- Paste the anchor into the HTML source of your template — directly into a static file, into the HTML view of your CMS, or into a component that is rendered server-side.
- Publish the page, open it in a normal browser, and confirm the visible text matches the intended address. Click the link once to confirm your mail client receives the intended target. Then view source and confirm the entities are still present and that the @ symbol and dot characters are not literal.
If your CMS decodes entities on save, you will see ordinary address characters in the saved HTML. If it double-escapes, you will see a and the page will render the entity text instead of the address. Either outcome means the obfuscation is gone, and the source needs to be edited at the template level rather than through the rich-text field.
Validation Rules the Obfuscator Applies
The validator is deliberately narrower than the full email standards quoted in RFC 5321 and 5322. It accepts one practical unquoted form because that covers nearly every real contact address while keeping the rule set auditable. Quoted local parts, comments, IP address literals, single-label hosts, and unusual legacy forms are rejected on purpose; a permissive validator that accepts exotic shapes but still produces a clickable anchor for an address that no human can recognize would mislead more than it would help.
The accepted shape requires one @ character, a nonempty local part, a domain with multiple labels separated by dots, no whitespace or control characters, and no leading, trailing, or consecutive dots in the local part. The local part keeps its original case and supports common punctuation such as plus signs, hyphens, underscores, and dots used for plus-addressing. The domain is lowercased before encoding.
The tool does not verify that the mailbox exists, that it accepts mail, or that it belongs to the person who typed it. A syntax-valid address can still bounce or be unmonitored. Treat validation here as a formatting check on what you will paste into HTML, not as proof that the address is usable.
| Accepted | Rejected | Reason |
|---|---|---|
| [email protected] | name@localhost | Single-label host not allowed |
| [email protected] | [email protected] | Leading dot in local part |
| [email protected] | [email protected] | IP literal not accepted |
| name@bücher.example (IDN) | name@@domain.tld | Repeated @ character |
| [email protected] | "quoted"@domain.tld | Quoted local part not supported |
Where This Approach Stops Helping
Entity encoding is obfuscation, not security. A human visitor who opens the rendered page sees the address plainly. A competent crawler can decode numeric character references, parse the DOM, walk the anchor's href, and extract the mailto target in a single pass. Anyone who clicks the link or copies it from the browser's status bar will see the resolved address, which is then fair game for whatever client they use.
The tool makes no promise that it will reduce spam and should never be treated as access control. For meaningful abuse resistance, the established defenses still apply: a server-side contact form with validation, rate limiting, and spam filtering; a disposable role address such as info@ or contact@ that you can rotate; mailbox provider controls such as custom rules, aliasing, and challenge-response; and never embedding secret addresses, credentials, or private aliases in a publicly rendered page.
JavaScript-dependent address injection is a different pattern that the tool explicitly avoids. Decoding the address at runtime through String.fromCharCode can fail when scripts are disabled, conflicts with strict content security policies, and adds moving pieces that static HTML does not need. Numeric references keep the result as ordinary HTML that any browser renders without executing code, which is also why the output is reproducible across viewers and easy to audit in source control.
Verify the Live Anchor After You Publish
The copy-paste step is the most common place for an entity-only anchor to fail in practice. A template can rewrite & to & on save; a CMS can decode entities because the rich-text editor treats HTML as content; an email-style composer can normalize punctuation. Treat the published page, not the editor preview, as the source of truth.
Open the live URL in a private window, view source, and confirm the @ symbol and dot characters are still encoded as numeric references. Click the link once to confirm the mail client receives the intended address. If the source shows ordinary characters, the obfuscation is gone and the page is now a normal mailto link with no source obscurity. Replace the field in your template so future edits preserve the entities.
For a deeper walkthrough of the encoding itself and how the entity-only anchor is structured, the email address encoder guide covers the same technique end to end. To return to the tool that produces the anchor described above, open the Email Address Obfuscator, enter the public address, and copy the resulting anchor straight into your HTML source.