mailto: links open a user's email client with prefilled fields.
They are fast to implement, but they are not a complete replacement for backend contact forms or APIs.
Basic mailto syntax
<a href="mailto:support@example.com">Email support</a>
Add subject and body
<a
href="mailto:support@example.com?subject=Need%20help&body=Hi%20team%2C%0A%0AI%20have%20a%20question..."
>
Contact support
</a>
Use URL encoding for spaces, line breaks, and special characters.
Common parameters
subject=...body=...cc=...bcc=...
Example with multiple fields:
<a href="mailto:sales@example.com?subject=Demo%20request&cc=ops@example.com"> Request demo </a>
Mailto limitations you must plan for
- depends on a configured email client,
- behavior varies by OS/browser/client,
- limited control over attachments and validation,
- not ideal for structured data capture.
For high-conversion contact paths, a server-side form/API is usually more reliable.
Security and spam considerations
Publishing raw email addresses can increase scraping risk.
Mitigations:
- use contact forms for primary support intake,
- avoid exposing high-value operational inboxes publicly,
- monitor aliases and rotate when abuse increases.
When to use mailto vs form/API
| Use case | Best option |
|---|---|
| Quick personal contact link | Mailto |
| Sales/support lead capture | Form/API |
| Structured issue intake | Form/API |
| Auditable workflow routing | Form/API + automation |
Testing checklist
- Verify link encoding for subject/body.
- Test behavior on major desktop and mobile clients.
- Confirm fallback UX when no client is configured.
- Check that spam-prone addresses are not overexposed.
- Add conversion tracking for form fallback.
Related routes
Final take
Mailto is useful for lightweight interactions. For scalable business workflows, pair it with form/API fallbacks so users are not blocked by client configuration issues.