What “[email protected]” means, and how to find the real address

Where the placeholder shows up

Cloudflare rewrites the page on its way to you. Each address in the text, and each address in an email link, becomes “[email protected]”, and a short script, email-decode.min.js, is added to the page to reverse the swap. In a browser that happens before you can notice, which is why Cloudflare’s documentation says visitors see no change. You see the placeholder wherever the script did not run:

• In a browser with JavaScript off, or with a script blocker that stops Cloudflare’s script. The placeholder is a link, and clicking it opens a Cloudflare page titled “Email Protection” that says the address was hidden from bots and asks you to enable JavaScript.
• In search results, which index the text the site served, placeholder included.
• In anything that reads the page’s source instead of the page a browser draws: text-only browsers, scrapers, and the page readers AI assistants use.

How to get the real address

Open the page itself, on the site, in an ordinary browser with JavaScript on, rather than the search result or the answer that quoted it. If you use a script blocker, allow that site. The address appears where the placeholder was, and the link opens your email app.

If all you have is the page’s source, the address is in it, encoded. Look for data-cfemail="…" beside the placeholder, or a link to /cdn-cgi/l/email-protection# followed by letters and digits. The value is hexadecimal: the first two characters are a key, and each following pair, combined with the key by XOR, is one character of the address. That is all Cloudflare’s decode script does. One line of Python does the same; this example value decodes to hello@example.com:

python3 -c "import sys; h=sys.argv[1]; print(''.join(chr(int(h[i:i+2],16) ^ int(h[:2],16)) for i in range(2, len(h), 2)))" 422a272e2e2d02273a232f322e276c212d2f

What AI assistants get instead

In September 2026 we gave five fresh Claude sessions, each with web search and page fetch, a customer’s questions about a live site whose addresses sat behind this setting. Three of the questions needed the site’s contact address, and none of the three could give it. The pages came back with the placeholder, and one assistant reported the address as “obfuscated by Cloudflare email protection on every page I fetched.”

In all three, the fetch tool also returned, at some point, an address that was not on the page: the site’s name under a different domain ending, a domain another company owns. That tool hands the assistant a smaller model’s reading of the page rather than the page itself. Each assistant distrusted it and gave no address at all, so the person asking was left without one. Asked the same questions about pages that served their addresses as plain text, Claude and OpenAI’s Codex found the address every time a question needed it.

The placeholder sits in search indexes as well. On September 28, 2026, an AI assistant’s web search for the phrase itself returned ordinary contact pages whose indexed text carried it, and the search tool’s own summary called “[email protected]” “a generic email pattern used by various organizations for their general contact inquiries.” If an assistant gives you an address for a site that shows the placeholder, check it on the site before you write to it.

An agent of your own meets the same wall. OpenClaw’s web_fetch tool is documented as a plain HTTP request with readable-text extraction that “does not execute JavaScript”, so on such a page it should read the placeholder, while the agent’s browser runs the page’s scripts like any browser and should see the address, going by the two tools’ documentation. An agent that has the raw HTML can also be given the decoding rule above.

If it’s your site

If your site is on Cloudflare and nobody has switched this off, it is on: Cloudflare enables it automatically at sign-up. The setting is a toggle in the Cloudflare dashboard: Security, then Settings (filter by Client-side abuse), then Email Address Obfuscation. Through the API it is the zone setting email_obfuscation. It rewrites addresses in the page’s text and in links’ href, and by Cloudflare’s documentation leaves these alone:

• addresses in any other HTML attribute
• anything inside script, noscript, textarea, xmp or head
• responses that are not HTML (text/html or application/xhtml+xml)
• responses sent with Cache-Control: no-transform, and HTML added by a Cloudflare Worker

The cost is that it hides your address from every reader that does not run your page’s scripts: the harvesters it was built to stop, and the assistants people now ask how to reach you. If you want an assistant to be able to answer that, the contact address has to be readable without script. Switch the toggle off for the whole site, switch it off for one hostname or path with a configuration rule, or exempt a single address with Cloudflare’s comment markers:

<!--email_off-->hello@example.com<!--/email_off-->

Putting the address in a noscript block gets it past Cloudflare and loses it anyway: Mozilla’s Readability, the library behind Firefox’s Reader View and the extractor OpenClaw’s web_fetch runs, deletes noscript content before it reads anything. What else page readers keep and drop is in how to make your website readable by AI agents. To check a page, fetch it the way an assistant does:

curl -sL https://example.com/contact | grep -c email-protection

Any number above zero means addresses on that page are still hidden.