Blog
Mailto links vs contact forms: which loses fewer leads?
· 3 min read
Every website eventually faces the same small decision: mailto: link or contact form? It looks cosmetic. It isn't - the two fail in completely different ways, and one of them fails silently.
How a mailto link actually behaves
<a href="mailto:you@example.com"> asks the visitor's operating system to open the default mail client. That assumption breaks constantly:
- Desktop users on webmail - a huge share of people read Gmail in a browser tab and have no desktop mail client configured. Clicking your link opens a blank Outlook setup wizard or nothing at all. The visitor shrugs and leaves.
- Shared and work computers - the configured client, if any, isn't theirs.
- The visitor's context is lost - they leave your page for another app, and any half-typed enthusiasm gets a dozen chances to evaporate.
The cruel part: you never see any of this. A broken form throws an error you can catch; a failed mailto is invisible. Your leads simply don't arrive, and the site looks like it "doesn't get enquiries."
There's a second cost: the address in the href is plain text in your HTML, harvestable by every scraper that crawls the web. That's a lifetime subscription to spam for the address you care about most.
How a contact form behaves
A form keeps the visitor on your page, works on every device with a browser (all of them), and gives you structure: you decide the fields, so every enquiry arrives with a reply address and enough context to act on. With a form backend behind it, you also get spam filtering, storage, and a notification the moment something arrives - without exposing an email address anywhere in your markup.
The trade-off is honest friction: a form is more markup than an anchor tag, and a badly designed one (ten required fields, hostile CAPTCHA) can lose more people than a mailto would. Keep it to email + message, and spam protection that's invisible to humans - honeypot and rate limiting first, a modern challenge like Turnstile only if pressure demands it. (See contact form spam protection.)
When a mailto is genuinely fine
- Personal pages and READMEs where volume is near zero and the audience is technical
- Situations where email is the deliverable - "press enquiries: press@…" lists in footers
- As a fallback line under your form: "form not working? email us at …" (use an obfuscation-friendly format if scraping worries you)
When a form pays for itself
The moment enquiries have monetary value - client work, product interest, bookings - the silent-failure mode of mailto is unacceptable. You can't measure what never arrives.
For static sites, adding the form is no longer the hard part; it's one attribute pointing at a form backend:
<form action="https://formhook.app/f/fh_your-key" method="POST">Submissions get stored, filtered, and pushed to your phone. The mailto link can stay - as the fallback, where it belongs.
Ship a working form in one line
EU-hosted, submissions kept forever, push notifications on every tier.
Start freeNo credit card · read the docs
Keep reading
- What is a form backend? (And when you need one)A form backend receives, stores, and forwards your website's form submissions so you don't run a server. Here's how they work and when you need one.
- How to add a contact form to GitHub PagesGitHub Pages can't run server code, but you can still have a working contact form. Three approaches compared, with a copy-paste solution that takes a minute.
- Contact form testing: the pre-launch checklistA broken contact form fails silently and costs leads for weeks. The 15-minute pre-launch checklist: happy path, validation, spam, mobile, and notifications.