action="mailto:you@example.com" doesn't send your form — it asks the visitor's device to open an email draft and send it themselves. No mail client configured (true for most mobile users) means nothing happens at all. Replace one attribute — point action at a real endpoint — and the same HTML form starts delivering, recording, and spam-filtering every submission.Point any HTML form at one endpoint. 500 free submissions — no card, no time limit — and unlimited forms.
Create free accountWhat mailto: actually does (and doesn't do)
The mailto: scheme predates forms themselves. When a browser encounters it as a form action, it does not perform an HTTP request. Instead it:
- URL-encodes your fields into a message body (as
name=valuepairs). - Hands that to the operating system's default mail client as a new draft.
- Waits. The submission only "sends" if a human then presses Send in Outlook, Apple Mail, or Thunderbird.
Every step leaks users. If no default client is configured — the normal state on phones, Chromebooks, and any browser-only Gmail user — the click does literally nothing. No error, no feedback. To the visitor, your form is broken; to you, the lead never existed.
The one-attribute fix
Keep your exact HTML — fields, styling, validation — and change only where it posts:
<!-- Before: relies on the visitor's mail app -->
<form action="mailto:you@example.com" method="POST" enctype="text/plain">
<!-- After: posts to a real endpoint -->
<form action="https://splitforms.com/api/submit" method="POST">
<input type="hidden" name="access_key" value="YOUR_ACCESS_KEY" />
<input name="name" required />
<input name="email" type="email" required />
<textarea name="message" required></textarea>
<button type="submit">Send</button>
</form>With splitforms, each accepted submission is saved in a searchable dashboard before owner notification email is attempted (so a bad mail day never loses a lead), and filtered by automatic spam scoring plus honeypot — free for 500 submissions total, no credit card. It works on any static host, and the same endpoint accepts AJAX/JSON posts if you later add JavaScript.
Alternatives and trade-offs — serverless functions, PHP mailer scripts, hosted builders — are compared in HTML form to email without PHP and sending form data without a server.
Where mailto: is still fine
As a plain link — "Email us" in a footer, or a support address in docs — mailto: is harmless and expected. Just never make it the submit path of a form whose submissions you care about. If you want a well-formed mailto link with subject and body prefill, use the mailto link generator. For the difference in outcomes, see contact form conversion benchmarks and how the form action attribute works.
Other form problems and fixes
- Contact form not working
- HTML form not submitting
- 405 Method Not Allowed
- 401 Unauthorized
- CORS error
- Form sends but no email arrives
- Emails land in spam
- Elementor form not sending
- Gravity Forms not sending
- Works in preview but not live
- Required attribute not working
- Form resubmission on refresh
- Duplicate form submissions
Still stuck? Test your endpoint with our free Form Action Tester or contact splitforms support.
FAQ
What happens when I use action="mailto:" on a form?
Instead of sending the submission to a server, the browser tries to open the visitor's default email application with a pre-filled draft containing the form data. The visitor then has to manually press Send in their mail app. Nothing is transmitted when they close the draft — and on most modern devices there is no configured default mail client at all, so nothing happens.
Why doesn't the mailto: form submit anything on my phone?
mailto: depends on a locally installed, configured email client. Most mobile browsers hand it to the OS mail app — if the user only uses Gmail in a browser tab, or hasn't set up the Mail app, the link does nothing. Desktop browsers increasingly do the same. There is no fallback and no error message; the form simply appears broken.
Is there any case where mailto: is acceptable?
Only as a plain 'Email us' link where the goal is to start a human conversation and losing some users is acceptable — never as the submit path of a lead, order, or support form. For those, you need a POST endpoint that records the submission server-side.
How much does mailto: hurt conversions compared to a real form?
We haven't found a published study that measures it, so we don't quote a multiplier — be wary of figures that come without a source. The mechanism is clear, though: a form is one click in-page, while mailto: needs a configured mail client, a context switch, and a second manual send, and every visitor who drops out at one of those steps is a lead you never see. A form also validates input, filters spam, and stores a copy; mailto: does none of these. To measure it on your own site, compare clicks on the mailto: button with the emails that actually arrive.
What should I use instead of mailto:?
Point the form at a form endpoint: action="https://splitforms.com/api/submit" method="POST" with a hidden access_key field. Accepted submissions are saved in a searchable dashboard before owner notification email is attempted, and spam-filtered — no backend code, no mail client required from your visitors. Free for 500 submissions total.
Can JavaScript make a mailto: form actually send?
No. JavaScript running in a browser cannot send email — there is no mail protocol access from the client for security reasons. Workarounds like EmailJS proxy through a third-party API (which is really a form backend with a different name). The reliable path is always an HTTP POST to a server you control or a hosted endpoint.
Swap the action once and every submission is delivered, stored, and spam-filtered. Get a free access key.
Related: form to email, receive submissions by email, and the HTML form action guide.