piapia123
en

Email Address Obfuscation

Encoding

Everything runs locally in your browser — nothing is uploaded

Input
Drop a file here to load its contents
Output

Convert an email address into forms that read normally and scrape uselessly. The idea is simple: write `me@example.com` as `me@…` — that is, HTML entities — and the browser renders it exactly as before — readers see it, click it and copy it with no difference at all. A spam crawler, meanwhile, picks up a run of entity characters, and unless it decodes entities specifically, the address never reaches its database. It is the least intrusive approach to this problem and has been for twenty years. ⚠️ But it stops ordinary address-harvesting crawlers and is not a security measure — a crawler that decodes HTML entities still gets it. Do not treat it as protection for an address you actually need to keep private; the only real option there is not publishing it in plain form at all (use a contact form).

Features

  • Five forms at once: decimal entities, hex entities, a ready-to-paste <a> tag, percent-encoding and JS escapes
  • "Encode only @ and ." mode: the page shows the plain address while a crawler no longer sees a usable one
  • A complete paste-ready link, with the address inside href encoded as well
  • Each row copies independently, so no hand-selecting from a long string
  • Runs entirely in the browser; the address is never uploaded anywhere

How to use

  1. Paste or type the email address into the input box
  2. Tick "encode only @ and ." if you want the source to stay readable
  3. Copy the ready-to-paste link row into your page source
  4. Check in a browser that it displays correctly and opens the mail client on click

FAQ

Does this actually stop spam crawlers?
It stops a good number of them, not all — plan around that. The vast majority of crawlers use a simple regex to pull `xxx@yyy.zzz` out of HTML, and entity encoding destroys that pattern, so they miss it. Crawlers built specifically to defeat obfuscation decode HTML entities first and will not be fooled. Treat it as a cheap measure with a limited payoff: a minute of effort that never hurts, but do not count on it to solve spam, and certainly do not use it to hide an address you need kept private.
What is the point of encoding only @ and .?
It keeps the change minimal. The page still shows me@example.com, because the browser turns `&#64;` back into @, while the source no longer contains a contiguous me@example.com string anywhere. A practical benefit: searching your own source for the address later still finds most of it, since `me` and `example` remain in plain text, so maintenance stays comprehensible. The cost is slightly weaker protection — against an experienced crawler the difference is small either way.
After pasting, the link does not work or displays wrong
First check which row you pasted. The ready-to-paste row is a complete `<a href="mailto:…">…</a>` and can go straight into the page body; if you only want the address text, use an entity row instead. Also note that pasting into Markdown, a rich-text editor or a CMS WYSIWYG mode may cause the editor to escape the entities again into `&amp;#109;`, which the browser then displays literally as `&#109;`. Switch to HTML source mode and paste there.
Is there a more thorough approach?
Three options, in increasing order of thoroughness. First, do not publish the address in plain form — use a contact form, or ask visitors to reach out another way. Second, replace it with an image, which crawlers cannot read but which is awkward to copy on mobile and cannot be read aloud by screen readers, so it has accessibility costs. Third, assemble the address in JavaScript after load, which is stronger than entity encoding but invisible to visitors with JS disabled. In practice: entity encoding is enough for a personal site with occasional posts, and anything commercial should use a form.

Related tools