Troubleshooting

Mailto form problems and what to use instead

Why a mailto form often fails, why the mailto action is not working for many visitors, and how a form backend fixes it with plain HTML.

Cover image: Mailto form problems and what to use instead, a FormDoc guide

A mailto form (a form with action="mailto:you@example.com") doesn’t send email itself. It asks the visitor’s device to open an email app with a draft, and the visitor still has to press Send there. If they have no email app set up, nothing happens at all. That’s why so many people find their mailto action not working. The reliable fix is to post the form to a form backend, which sends the email for you.

How a mailto form is supposed to work

The idea looks simple:

<form action="mailto:you@example.com" method="POST" enctype="text/plain">
  <input type="text" name="name">
  <textarea name="message"></textarea>
  <button type="submit">Send</button>
</form>

When someone presses Send, the browser builds a mailto: link from the field values and hands it to whatever the operating system has registered as the email app. The email app opens a new message, and the visitor is expected to send it from their own account.

So the form never “submits” in the usual sense. No data leaves the page until the visitor finishes a second step in a different program.

Why the mailto action is not working

Here are the common reasons a mailto form fails, roughly in the order people run into them:

  1. No email app is configured. Many people read email in a browser tab. On their computer, a mailto: link either does nothing or opens a mail app they’ve never set up.
  2. The wrong app opens. The system default might be an app the visitor doesn’t use, so they close it and give up.
  3. The visitor doesn’t press Send. The draft opens, the visitor gets distracted, and the message never goes. You’ll never know it was attempted.
  4. The body is mangled. Browsers handle form data in mailto: links inconsistently. Line breaks, special characters and field names can arrive jumbled or not at all.
  5. Mobile behaviour varies. Phones may switch apps, lose the form contents or open a share sheet instead.
  6. No spam protection or confirmation. There’s no honeypot, no rate limit and no thank-you page, because nothing on your side ever sees the submission.
  7. Your address is exposed. The email address sits in your page source, where scrapers collect it.

None of these can be fixed with better HTML. They come from the design: a mailto form depends entirely on the visitor’s device.

The worst part is that failures are silent. When a mailto form doesn’t work, you don’t get an error report. The visitor simply leaves, and from your side it looks like nobody tried to get in touch. If your contact form seems unusually quiet, a mailto action is one of the first things to check.

Mailto vs form backend

A form backend receives the post on a server and sends the email for you. The visitor presses Send once and they’re done.

Mailto form Form backend
Needs an email app on the visitor’s device Yes No
Visitor must press Send twice Yes No
You know a message was sent No Yes, it’s stored and emailed
Field formatting Unreliable Readable table in the email
Spam protection None Honeypot, scoring, rate limits, optional captcha
Your email address in page source Yes No, only a public access key
Thank-you page or message No Hosted page, your own redirect, or inline message
Works the same on phones No Yes

The one thing a mailto form has going for it is that it needs no account. A form backend can match that: FormDoc gives you a key after you confirm your email address, with no sign-up.

If you’re new to the idea, what is a form backend explains the concept in plain terms.

Replace a mailto form in three steps

You can keep your fields and layout. Only the form tag and two hidden inputs change.

  1. Get a free access key at https://app.formdoc.dev/new by entering the address that should receive messages and clicking the confirmation link.
  2. Change the form’s action to FormDoc’s endpoint and remove enctype="text/plain".
  3. Add the hidden access_key field and the botcheck honeypot.
<form action="https://api.formdoc.dev/v1/submit" method="POST">
  <input type="hidden" name="access_key" value="YOUR_ACCESS_KEY">

  <label for="name">Name</label>
  <input id="name" type="text" name="name" required>

  <label for="email">Email</label>
  <input id="email" type="email" name="email" required>

  <label for="message">Message</label>
  <textarea id="message" name="message" required></textarea>

  <input type="checkbox" name="botcheck" style="display:none" tabindex="-1" autocomplete="off">
  <button type="submit">Send</button>
</form>

Note the new email field. With a mailto form you got the visitor’s address automatically, because they sent from their own account. With a form backend, ask for it. FormDoc sets the Reply-To header to that address, so pressing Reply in your inbox answers the visitor directly, just like before.

The full walkthrough, including subject lines and redirects, is in how to send an HTML form to email without PHP.

A mailto link (not a form) is still useful. Many visitors like to see an address they can copy or click:

<a href="mailto:hello@example.com">hello@example.com</a>

This is honest about what happens: it opens an email app. Visitors who prefer email use it, and everyone else uses the form. Offering both is common on contact pages.

What doesn’t work well is dressing a mailto link up as a form, because visitors expect a form to send when they press the button.

After you switch

Once the form posts to a backend, a few things improve without extra work:

  • Every submission is stored, so a message can’t vanish between two apps.
  • Spam is filtered before it reaches you, and never emailed.
  • Visitors see a clear confirmation, either FormDoc’s hosted thank-you page or your own page via a redirect field.
  • You can add the optional formdoc.js script to show success inside the form without leaving the page.

Common questions

Why does my mailto form open Outlook or Mail instead of sending?

That’s how mailto: works. The browser passes the data to the default email app, which opens a draft for the visitor to send. A form can’t send email on its own; it needs a server or a form backend to do it.

Can I make a mailto form send automatically?

No. Browsers deliberately don’t let a web page send email from a visitor’s account without them pressing Send. To send automatically, post the form to a service that sends the email on your behalf.

Will I still be able to reply to visitors after switching?

Yes. Ask for the visitor’s email in a field named email. FormDoc uses it as the Reply-To address on the notification, so your reply goes straight to them.

Fix it in a few minutes

If your current form uses mailto:, the contact form template is a drop-in replacement with labels and the honeypot ready. Swap in your key and it will send every time, on every device.

Keep reading