# Mailto Form in HTML: Why It Fails and What to Use

Mailto form in HTML: action, method post and text/plain. Why the mail app opens, why messages never arrive, and what to use instead of form action email.

Author: Formgong team
Published: 2026-10-05
Updated: 2026-10-06
Language: en
Canonical: https://formgong.com/en/blog/mailto-form-vs-form-backend/

A mailto form puts a mailto: address in the action. The browser builds an email draft and hands it to the visitor's mail app. It sends no HTTP request. The page never learns if the visitor pressed Send. A mailto link is fine as an email button. A contact form should post to a form backend.

## What a mailto form actually does

A normal form sends its fields to a web address. A mailto form has an email address in its `action` instead. The HTML standard says what the browser does with it, and it never sends the email for you.

- With `method="GET"`, the browser turns the fields into the subject and headers of a new email.

- With `method="POST"`, the browser puts the fields in the body of a new email. With `enctype="text/plain"` the body is readable. Without it, the text is URL-encoded and hard to read.

In both cases the browser opens the visitor's mail app with a draft. The visitor still has to press Send in that app. Your page gets no answer back, so it cannot tell whether a message left.

The HTML standard is clear about the hand-off. The browser does not open an HTTP connection to your site, and it does not contact a mail server. It builds a `mailto:` URL and gives that URL to the program the operating system has registered for the mailto scheme. If nothing is registered, the click can do nothing. This page does not claim what a particular mail app then shows. That part is outside the standard.

## How to use mailto in an HTML form

A mailto form needs three attributes together. `action` is a `mailto:` URL, not a bare address. `method` is `post` when you want the fields in the body. `enctype` is `text/plain` when you want that body to be readable. Replace `you@example.com` with the address that should receive the draft.

`action` must be a URL. `form action email` searches often mean `action="you@example.com"` with no scheme. That value is not a mailto URL. Browsers treat it as a path on your site, so the fields are not handed to a mail app and no email is sent. Write `mailto:` in front of the address, or do not use mailto at all.

Here is what the visitor's device does after Submit, and only this much:

- The browser collects the fields. It does not send them to your host. A network panel shows no request to your page for that click.

- With `method="post"` and `enctype="text/plain"`, the fields become the body of a new message. Each field is one line, `name=value`.

- The browser asks the operating system to open the mailto handler. That is usually a mail app, if one is installed and set as the default.

- The visitor still has to press Send inside that app. Your page is not told the result. There is no thank-you state you can trust.

The W3Schools mailto form does the same thing. Their example uses `action="mailto:…"`, `method="post"` and `enctype="text/plain"`, and the mail client opens. That is the expected result, not a bug in the example. If nothing opens, the device has no mailto handler. The tutorial cannot fix that.

A mailto link can still set a subject and a first line. The format is in the next section, from RFC 6068. For a form that should work without a mail app, use the [HTML form action](/en/blog/html-form-action/) guide and post to an `https` address. A full working form is in the [HTML contact form without a backend](/en/blog/html-contact-form-without-backend/).

```html
<form action="mailto:you@example.com" method="post" enctype="text/plain">
  <label>Name <input type="text" name="name" autocomplete="name"></label>
  <label>Email <input type="email" name="email" autocomplete="email"></label>
  <label>Message <textarea name="message"></textarea></label>
  <button type="submit">Send</button>
</form>
```

## Why mailto forms lose messages

Each step after the click depends on the visitor's device. That is where messages get lost:

- **No mail app.** Many people read email in a browser tab. If no mail app is set as the default, the click may do nothing, or the system asks which app to use.

- **No Send.** The draft opens and the visitor closes it, gets distracted, or thinks the form already sent it.

- **No confirmation.** Your page cannot show "Thanks, we got it", because it never learns the result.

- **No copy for you.** Nothing is stored, so a lost message is gone for good.

- **Exposed address.** Your email address sits in the page source, where scrapers collect it for spam.

- **Messy data.** Without `text/plain`, the body arrives as `name=Alex&message=Hi%20there`.

The visitor also sends from their own account. Some people do not want to share their personal address with a business they do not know yet.

Files are a separate failure. A mailto form has no reliable way to attach a PDF or a photo. Mail apps disagree about what to do with file fields, and many drop them. If the form must accept a file, post it to a backend that states its limits.

## Mailto form vs a form backend

Use mailto when a click should open the visitor's own mail app, and you can accept lost drafts. Use a form backend when you need the message stored, a confirmation on the page, and your address kept out of the HTML.

What you get with a mailto form and with a form backend. Mailto behaviour follows the HTML standard and RFC 6068.
Mailto formForm backend
Delivery confirmationNone. The page never hears whether Send was pressed.The server stores the message and can show a thank-you page.
SpamYour address is in the page, so scrapers can mail you directly. The form has no spam filter.The address stays off the page. A honeypot and server filters can drop bots.
Address exposureThe inbox address must be in the HTML.Visitors post to a URL. Your address stays in the dashboard.
Mobile and webmailNeeds a mail app. Webmail in a browser tab often has nothing to open.Works in the browser. No mail app is required.
FilesNot reliable. Many mail apps drop file fields.A backend can accept files, with the limits it publishes.

Formgong is one backend, not the only one. On the Free plan, email arrives as a next-morning daily digest at 08:00 in the account owner's time zone, to one recipient. Telegram is instant. Pro emails each submission to up to three recipients. Business allows five. A PHP script on your own host is the other honest option, and then you handle spam and delivery yourself. The wider list is in [form without a backend](/en/blog/form-without-backend/).

## When a mailto link is still fine

A plain mailto link is a different thing from a mailto form. It is honest: the visitor clicks "Email us" and expects their mail app to open. That works well as a second contact option next to a form, or for people who prefer email.

You can fill in the subject and the first line of the body with the link. The format is defined in RFC 6068. Encode spaces and line breaks, or some mail apps cut the text.

**A mailto link with a subject and body**

```html
<!-- Spaces become %20 and line breaks become %0D%0A. -->
<a href="mailto:hello@example.com?subject=Project%20enquiry&body=Hi%2C%0D%0A%0D%0AI%20would%20like%20to%20ask%20about">
  Email us about a project
</a>
```

## Replace the mailto form with a working one

Keep your fields and change two things: the `action` and a hidden key. The form then posts to a form backend. The backend stores the message and shows the visitor a thank-you page. Nothing depends on their mail app.

On the Free plan, email is not instant. It arrives as a next-morning daily digest at 08:00 in the account owner's time zone, to one recipient. Telegram is instant. Pro emails each submission to up to three recipients. Business allows five. Prices are on the [pricing](/en/pricing/) page.

The example below uses Formgong. Replace `fk_your_access_key` with the key from your dashboard. The `_subject` field sets the subject of your notification. The hidden `botcheck` field catches simple bots. Your address no longer appears in the page. The same shape, ready to paste, is the [HTML contact form template](/en/templates/html-contact/). Setup for a static page is on [the HTML contact form page](/en/for/html/).

```html
<!-- Before: <form action="mailto:you@example.com" method="POST" enctype="text/plain"> -->
<form action="https://formgong.com/submit" method="POST">
  <input type="hidden" name="access_key" value="fk_your_access_key">
  <input type="hidden" name="_lang" value="en">
  <input type="hidden" name="_subject" value="New message from the website">
  <label>Name <input type="text" name="name" required autocomplete="name"></label>
  <label>Email <input type="email" name="email" required autocomplete="email"></label>
  <label>Message <textarea name="message" required></textarea></label>
  <div aria-hidden="true" style="position:absolute;inset-inline-start:0;top:0;width:1px;height:1px;overflow:hidden;clip-path:inset(50%)">
    <input type="text" name="botcheck" tabindex="-1" autocomplete="off">
  </div>
  <button type="submit">Send</button>
</form>
```

## Other ways to receive form data

- **A form backend.** Change the action and you are done. Formgong, Formspree, Web3Forms and others work this way. The [form backend comparison](/en/compare/) shows the differences in limits and features. If you are leaving Web3Forms specifically, see the [Web3Forms alternatives](/en/web3forms-alternative/) roundup.

- **Your own script.** A PHP file or a serverless function receives the post and sends the mail. You control everything, and you also fix the mail delivery and spam yourself.

- **A hosted form.** Google Forms and similar tools give you a link or an embed. Quick, but it looks like their product, not your site.

Our [HTML contact form guide](/en/blog/html-contact-form-without-backend/) goes through a complete form step by step. The [HTML docs](/en/docs/html/) list every hidden field Formgong understands.

## Check your form before you publish

Paste your form's HTML into the [free form checker](/en/tools/form-checker/). It flags an `action` that is not a web address, such as `mailto:`, as an error. It also checks field names, the method and the honeypot.

Then send a real test from the published page on a phone and on a laptop. Check that the message arrives and that the visitor sees a clear thank-you page.

## Frequently asked questions

### Does a mailto form send email?

No. The browser only opens the visitor's mail app with a draft. The message is sent only if a mail app is set up and the visitor presses Send there.

### Why does my mailto form do nothing on click?

Usually no default mail app is set on that device. Many people use webmail in a browser tab, and then the click has nowhere to go.

### Can I hide my email address in a mailto form?

No. The address must be in the page so the browser can use it, which means bots can read it too. A form backend keeps your address out of the page.

### Is a mailto link bad for SEO?

No. A mailto link is a normal link that search engines ignore. The problem is lost messages, not rankings.

### Does form action email send the message?

No. The action value must be a URL. An email address alone, with no mailto: scheme, does not send mail. action="mailto:you@example.com" only opens a draft. It still does not send until the visitor presses Send in a mail app.

## Sources and documentation

- [HTML Standard: form submission](https://html.spec.whatwg.org/multipage/form-control-infrastructure.html)
- [RFC 6068: The mailto URI scheme](https://datatracker.ietf.org/doc/html/rfc6068)
- [MDN: the form element](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/form)
- [Formgong HTML integration](https://formgong.com/en/docs/html/)

[Get a form key](https://formgong.com/en/#top)