How mailto: Links Work
Learn how mailto: links work, how their syntax is structured, which parameters can be used, and how to create reliable email links for websites and applications.
A mailto: link is a special type of URL that allows a webpage, application, or document to open the user's default email client with a recipient address already filled in. It can also include a subject, message body, and additional recipients, making it useful for contact links, support buttons, feedback forms, and other communication workflows.
Unlike a normal web URL, a mailto: link does not point to a webpage. Instead, it describes an email message that an email application can prepare for the user. The message is normally not sent automatically; the user reviews it and chooses whether to send it.
What Is a mailto: Link?
A mailto: link is a URI that uses the mailto scheme. The simplest form contains an email address after mailto: and can be used directly in an HTML anchor element.
<a href="mailto:hello@example.com">Email us</a>When the user activates the link, the operating system or browser attempts to open the configured email application or mail handler. The recipient field is populated with hello@example.com.
Basic mailto: Syntax
The basic structure is straightforward: the mailto scheme is followed by one or more recipient addresses. Optional parameters are added after a question mark.
mailto:recipient@example.com
mailto:recipient@example.com?subject=Hello
mailto:recipient@example.com?subject=Hello&body=Message| Part | Example | Purpose |
|---|---|---|
| Scheme | mailto: | Identifies the URI as an email link. |
| Recipient | user@example.com | Specifies the email recipient. |
| Query separator | ? | Begins optional email parameters. |
| Parameter separator | & | Separates multiple parameters. |
| Parameter | subject=Hello | Provides a value such as the email subject. |
Creating a mailto: Link in HTML
The most common use of mailto: links is inside HTML anchor elements. The href attribute contains the complete mailto URI while the visible text describes the action.
<a href="mailto:support@example.com">Contact support</a>A descriptive link label is preferable to displaying the raw email address when the surrounding context already explains where the link leads. This can also make the interface easier to understand for keyboard and assistive-technology users.
Adding a Subject
The subject parameter lets a website prefill the email subject. Because the value is part of a URI, spaces and special characters should be percent-encoded.
<a href="mailto:support@example.com?subject=Website%20Support">Email support</a>A subject such as Website Support becomes the initial subject in the user's email client. URL encoding is important when the value contains spaces, ampersands, question marks, or other characters with special meaning in a URI.
Adding an Email Body
The body parameter can be used to prefill the message content. Line breaks should be encoded appropriately rather than inserted as raw characters into the URI.
<a href="mailto:support@example.com?subject=Support%20Request&body=Hello%2C%0A%0AI%20need%20help%20with...">Contact support</a>In this example, %0A represents a line break and %20 represents a space. Proper encoding prevents characters in the message from being interpreted as part of the URI syntax.
Multiple Recipients
Multiple recipient addresses can be specified in the mailto URI by separating them with commas. This allows a single link to prepare a message addressed to several recipients.
<a href="mailto:alice@example.com,bob@example.com">Email the team</a>For more complex messages, additional headers such as cc and bcc can be represented as parameters. Support for particular parameters can vary between email clients, so critical workflows should not depend exclusively on a mailto: link.
CC and BCC Parameters
The cc parameter can specify additional carbon-copy recipients, while bcc can specify blind-copy recipients. They are included as query parameters alongside subject and body.
mailto:primary@example.com?cc=team@example.com&bcc=archive@example.com&subject=ReportURL Encoding in mailto: Links
URL encoding is one of the most important details when building mailto: links. Characters such as spaces, ampersands, question marks, and line breaks can have special meanings inside a URI.
| Character or Value | Encoded Form | Typical Use |
|---|---|---|
| Space | %20 | Separating words |
| Line break | %0A | Creating multiple lines in the body |
| & | %26 | Including an ampersand as message content |
| ? | %3F | Including a question mark as message content |
| # | %23 | Including a hash character as message content |
For example, the body value Hello & welcome should not place a raw ampersand into the parameter value because & separates query parameters. Encoding it as Hello%20%26%20welcome makes its intended meaning unambiguous.
Generating mailto: Links with JavaScript
When recipient, subject, or body values come from application data, constructing the URI programmatically is safer than concatenating unescaped strings.
const recipient = "support@example.com";
const subject = encodeURIComponent("Support request");
const body = encodeURIComponent("Hello,\n\nI need help with my account.");
const mailto = `mailto:${recipient}?subject=${subject}&body=${body}`;
console.log(mailto);The recipient is handled separately from the subject and body because different components of a URI have different encoding requirements. When accepting recipient addresses from users, validate them according to the application's requirements before constructing the link.
mailto: Links Do Not Send Email Automatically
A common misconception is that clicking a mailto: link sends an email. In normal usage, it only asks the user's system to open an email handler and prepare a message. The user generally remains responsible for reviewing and sending it.
This makes mailto: links simple and useful, but it also means they depend on the user's environment. A device without a configured mail application may not provide a useful experience.
Advantages of mailto: Links
- They are simple to implement with standard HTML.
- They require no server-side email API for the basic use case.
- They can prefill recipients, subjects, and message content.
- They work naturally with desktop and mobile email applications that support the mailto scheme.
- They are useful for simple contact, support, and feedback actions.
Limitations of mailto: Links
- They depend on the user's email client or configured mail handler.
- They do not guarantee that a message will actually be sent.
- Long message bodies can produce inconveniently long URLs.
- Behavior can differ between browsers, operating systems, and email applications.
- They are not suitable when an application needs reliable server-side delivery or automated email sending.
mailto: Links vs Server-Side Email Forms
| Feature | mailto: Link | Server-Side Form |
|---|---|---|
| Email client required | Usually yes | No |
| Automatic sending | No | Yes, if configured |
| Implementation | Very simple | More complex |
| Message control | Limited | Greater control |
| Delivery tracking | Limited | Can be implemented |
| Best for | Simple contact actions | Managed application workflows |
A mailto: link is a good choice when the goal is simply to let users start an email in their preferred application. A server-side form is usually better when the application needs controlled delivery, validation, spam protection, logging, attachments, or transactional email behavior.
Common mailto: Mistakes
- Forgetting to encode spaces and special characters.
- Putting an unencoded ampersand inside a subject or body value.
- Assuming every browser and email client handles every parameter identically.
- Expecting mailto: to send messages without user interaction.
- Including sensitive data in the URI.
- Using mailto: for workflows that require guaranteed server-side delivery.
Accessibility Considerations
A mailto: link should have descriptive text that communicates its purpose. For example, Contact support is generally clearer than a generic Click here label. If the destination address is important information, displaying the address alongside the link can also help users understand what will happen.
<a href="mailto:support@example.com?subject=Support%20Request">
Contact support
</a>When Should You Use a mailto: Link?
Use a mailto: link when you want users to initiate an email using their own email application and the workflow does not require guaranteed server-side processing. It works particularly well for simple support contacts, business inquiries, feedback links, and personal websites.
For registration, transactional notifications, support ticket creation, marketing campaigns, or other workflows where the application must control delivery, a server-side email system is usually more appropriate.
Practical mailto: Checklist
- Use the mailto: scheme followed by the intended recipient.
- Encode subject and body values correctly.
- Encode special characters such as ampersands when they are message content.
- Use clear and descriptive link text.
- Avoid putting sensitive information into mailto: URLs.
- Test links with the browsers and email clients your users are likely to use.
- Use server-side email delivery when reliable automated sending is required.
What is a mailto: link?
A mailto: link is a URI that opens the user's configured email application and can prefill an email recipient, subject, body, and other supported fields.
Does a mailto: link send an email automatically?
No. It normally opens an email client with a prepared message. The user generally needs to review and send the message themselves.
How do I add a subject to a mailto: link?
Add a subject query parameter after the recipient, for example mailto:user@example.com?subject=Hello. The subject should be URL-encoded when it contains spaces or special characters.
How do I add a message body to a mailto: link?
Add a body parameter, such as mailto:user@example.com?body=Hello%20there. URL encoding should be used for spaces, line breaks, and special characters.
Can a mailto: link have multiple recipients?
Yes. Multiple recipients can be specified, and additional recipients can also be provided through supported parameters such as cc and bcc.
Why should mailto: parameters be URL-encoded?
Encoding prevents spaces and special characters from being interpreted as part of the URI structure instead of as the intended email content.
When should I use a server-side email form instead?
Use server-side email delivery when the application needs reliable sending, centralized validation, spam protection, delivery tracking, attachments, or automated email workflows.
Conclusion
mailto: links provide a simple way to connect a webpage with a user's email application. They can populate recipients, subjects, message bodies, and additional recipient fields without requiring a dedicated email backend.
Their simplicity also comes with limitations. Mailto: links depend on the user's environment, do not guarantee message delivery, and require careful URL encoding. For straightforward email actions they remain useful, while applications that need reliable automated delivery should use a server-side email solution.