Protecting your email address via SVG instead of JavaScript

Original Article ↗ Hacker News Discussion ↗

Effectiveness of the SVG Technique

  • The email remains plain text inside an SVG (XML) file; simple tools (curl/wget + grep for mailto:) can still extract it.
  • Critics see it as “security through obscurity” and very easy to bypass, especially once bots are updated.
  • Supporters argue many basic scrapers only parse HTML and DOM anchors, not external SVGs, so this blocks a real subset of naive tools.
  • Several note this just shifts which bots you’re vulnerable to: it may stop DOM-based scrapers but reopens you to raw-text greppers if they fetch all assets.

Scraper Behavior and Arms Race

  • Some claim most simple scrapers never execute JS or build a DOM; they just recursively fetch HTML and regex for emails.
  • Others point out many “advanced” scrapers are headless browsers (Chromium-based) that render SVGs, query DOM, and could even apply OCR/AI to images.
  • Consensus: this technique at best filters out a “middle tier” of bots; widespread adoption would likely lead scraper authors to add SVG parsing.

Accessibility and Usability

  • Multiple tests with screen readers show inconsistent behavior:
    • Sometimes the email link is focusable but announced only as generic text like “Email us.”
    • Sometimes the SVG link is ignored entirely in certain browser + screen reader combinations.
  • Voice dictation tools may not activate the link when users speak the visible email, due to mismatched labels.
  • Terminal browsers generally fail to expose the address.
  • Users also note copy-paste is unreliable (selecting visible text often doesn’t copy the address).

Is Obfuscation Still Necessary?

  • Many report having plain mailto links for years with minimal problematic spam; modern filters catch most of it.
  • Several suggest spam now primarily comes from data breaches, contact list harvesting, and bought lists rather than web scraping.
  • Others self-hosting mail or using public addresses do see noticeable spam on exposed addresses, so experiences differ.
  • A recurring view: this is largely a preference issue now, not a major security control.

Alternative Approaches Mentioned

  • HTML entities for every character of the address.
  • Splitting the address across hidden <span>s.
  • Unique aliases per service or per website, often with catch-all domains.
  • Contact forms or routing “public” emails into filtered folders.
  • Simply publishing the email and relying on spam filters.