Protecting your email address via SVG instead of JavaScript

Original Article ↗ Hacker News Discussion ↗

A proposal to “protect” email addresses by rendering them inside SVG images instead of HTML or JavaScript mailto links aims to evade simple scraping bots. Commenters question whether this meaningfully deters modern spammers—who increasingly rely on breached data, headless browsers, or OCR—and note that spam filters are generally effective enough that such obfuscation may be unnecessary. Several also highlight drawbacks, including accessibility problems for screen readers and added complexity compared to simpler options like contact forms or disposable aliases.

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.