mailto: Links Explained

A mailto: link is a special type of link that allows a website or document to open the user's configured email application with a new message prepared for a specified recipient. Instead of navigating to another web page, clicking the link can open a desktop mail client, webmail interface or another application capable of handling email links.

The simplest mailto: link contains only an email address. However, the URI format can also include information such as a subject, message body, CC recipients and BCC recipients. This makes mailto: useful for contact pages, support links, feedback buttons, documentation and other situations where a website needs to make starting an email conversation convenient.

At the same time, mailto: links have limitations. They depend on the user's device and configured email handler, they cannot send messages by themselves, and incorrectly encoded special characters can produce broken subjects or message bodies. Understanding the syntax helps avoid these problems.

What Is a mailto: Link?

A mailto: link is a URI that identifies an email address as the destination of a link. In HTML, it is normally placed inside an anchor element using the href attribute.

<a href="mailto:[email protected]">
  Email us
</a>

When the user activates the link, the operating system or browser determines which application or service should handle the mailto: URI. Depending on the user's configuration, this could be a desktop email client, a browser-based mail service or another registered mail application.

The Simplest mailto: Syntax

The basic syntax consists of the mailto: scheme followed by an email address.

mailto:[email protected]

As an HTML link, it becomes:

<a href="mailto:[email protected]">
  [email protected]
</a>

The visible text of the link does not have to match the email address. For example, a website can display a call-to-action such as Contact support while the href contains the actual mailto: URI.

<a href="mailto:[email protected]">
  Contact support
</a>

Adding a Subject

A subject can be added using the subject parameter after a question mark.

mailto:[email protected]?subject=Website%20Question

The %20 sequence represents a space because mailto: parameters use URI encoding. The same link in HTML is:

<a href="mailto:[email protected]?subject=Website%20Question">
  Contact support
</a>

Some contexts also accept a literal space after decoding, but properly encoding spaces and other reserved characters is the safer approach when constructing a mailto: URI.

Adding a Message Body

A body parameter can prefill the email message. It is separated from the subject parameter using an ampersand.

mailto:[email protected]?subject=Website%20Question&body=Hello%2C%20I%20have%20a%20question.

When the user clicks the link, the email application can create a new message containing the specified subject and body.

A Complete HTML Example

<a
  href="mailto:[email protected]?subject=Website%20Question&body=Hello%2C%20I%20have%20a%20question."
>
  Contact support
</a>

The browser does not send this email. It passes the mailto: URI to the appropriate handler, which then prepares the message.

How mailto: Links Actually Work

A mailto: link is fundamentally a request to handle an email URI. The browser and operating system are responsible for determining what application should handle that URI.

• The user clicks or activates the mailto: link.
• The browser recognizes the mailto: URI scheme.
• The browser or operating system finds a registered mail handler.
• The handler receives the recipient and optional message parameters.
• The email application opens a compose interface when supported.
• The user reviews and sends the message manually.

This distinction is important: mailto: is not an email-sending API. It does not provide server-side delivery, authentication, delivery tracking or guaranteed sending.

mailto: Does Not Send Email Automatically

One of the most common misconceptions is that a mailto: link can send an email directly. It cannot. The link only prepares an email in the user's configured mail application.

Using URL Encoding in mailto:

Because mailto: is a URI scheme, values inside its query parameters need appropriate encoding. Characters such as spaces, ampersands, question marks, percent signs and line breaks can have special meaning in a URI.

The important principle is that the parameter value must be encoded as data rather than being allowed to interfere with the structure of the URI.

Why the Ampersand Is Important

The ampersand separates parameters in the mailto: query portion.

mailto:[email protected]?subject=Hello&body=Message

Here, subject and body are separate parameters. But if the body itself contains an ampersand, that character should be encoded.

mailto:[email protected]?subject=Hello&body=Company%20A%20%26%20Company%20B

Without encoding the ampersand inside the body, it could be interpreted as the beginning of another parameter.

Using JavaScript to Encode mailto: Values

When a mailto: URI is generated dynamically, JavaScript can encode individual parameter values with encodeURIComponent().

const recipient = "[email protected]";
const subject = "Website question";
const body = "Hello, I have a question about the documentation.";

const mailto = [
  `mailto:${recipient}`,
  `?subject=${encodeURIComponent(subject)}`,
  `&body=${encodeURIComponent(body)}`,
].join("");

console.log(mailto);

Encoding individual values is usually clearer than trying to encode the entire mailto: URI as one string. The scheme, recipient and parameter separators have structural meaning and should remain intact.

Do Not Encode the Entire mailto: URI Blindly

A common implementation mistake is passing the complete mailto: string through encodeURIComponent(). That can encode characters that are supposed to remain part of the URI structure, including the colon, question mark and ampersands.

const subject = "Website question";
const body = "Hello!";

const mailto =
  `mailto:[email protected]?subject=${encodeURIComponent(subject)}&body=${encodeURIComponent(body)}`;

Multiple Recipients

Multiple email addresses can be specified in the recipient portion of a mailto: URI. Addresses are separated according to the mailto URI syntax.

mailto:[email protected],[email protected]

Support and formatting can vary between email clients, so multiple-recipient mailto: links should be tested in the environments where they will be used.

CC Recipients

The cc parameter can specify additional recipients who should receive a copy of the email.

mailto:[email protected][email protected]

Multiple CC recipients can also be represented according to the mailto URI syntax.

BCC Recipients

The bcc parameter can be used to prefill blind-copy recipients.

mailto:[email protected][email protected]

BCC should be used carefully in public links because the recipient is embedded in the URI. Anyone who can inspect the link can potentially see the intended BCC address before the email is sent.

Combining To, CC, BCC, Subject and Body

mailto:[email protected][email protected]&[email protected]&subject=Support%20Request&body=Hello%2C%20I%20need%20help.

The order of query parameters is generally not important, but separating and encoding each value correctly makes generated links easier to maintain.

Multiline Email Bodies

A mailto: body can contain line breaks. New lines need to be represented using appropriate percent-encoded characters.

mailto:[email protected]?body=Hello%2C%0A%0AI%20have%20a%20question.%0A%0AThank%20you.

After decoding, the body is equivalent to a message with blank lines between the paragraphs.

Creating a Multiline mailto: Link in JavaScript

const body = [
  "Hello,",
  "",
  "I have a question about the product.",
  "",
  "Thank you.",
].join("\n");

const mailto =
  `mailto:[email protected]?body=${encodeURIComponent(body)}`;

Generating the body as an ordinary string first makes the content easier to read and maintain. The complete body can then be encoded as a single parameter value.

Prefilling an Email Subject with Useful Information

A predefined subject can help organize incoming messages. For example, a support page might use a subject such as Product Support Request or Account Question.

<a
  href="mailto:[email protected]?subject=Product%20Support%20Request"
>
  Contact support
</a>

This does not force the user to keep the subject. The user can normally edit the prepared message before sending it.

Dynamic mailto: Links

Applications can generate mailto: links based on information already available in the interface. For example, a product page could prepare an email containing a product name or reference number.

function createMailto({ recipient, subject, body }) {
  const params = new URLSearchParams({
    subject,
    body,
  });

  return `mailto:${recipient}?${params.toString()}`;
}

const link = createMailto({
  recipient: "[email protected]",
  subject: "Product question",
  body: "I have a question about the product.",
});

console.log(link);

URLSearchParams can be useful for constructing query parameters because it handles percent-encoding of parameter values. The recipient remains outside the query string and should be handled separately.

Using mailto: in React

In React, a mailto: URI can be assigned directly to an anchor element's href attribute.

export function ContactLink() {
  return (
    <a href="mailto:[email protected]">
      Email us
    </a>
  );
}

For dynamic values, construct the URI before rendering or inside a small helper function.

const subject = "Project question";
const body = "Hello, I would like to ask about the project.";

const href =
  `mailto:[email protected]?subject=${encodeURIComponent(subject)}&body=${encodeURIComponent(body)}`;

return <a href={href}>Email us</a>;

Using mailto: in Next.js

A mailto: link does not require a server route or API endpoint. It can be rendered directly in a Next.js component just like an ordinary HTML anchor.

export default function ContactPage() {
  return (
    <main>
      <h1>Contact</h1>

      <a href="mailto:[email protected]?subject=Website%20Question">
        Send an email
      </a>
    </main>
  );
}

This can be useful when the purpose of the page is simply to give users a convenient way to contact a person or organization without implementing an email form.

mailto: Links vs Contact Forms

The choice depends on the goal. A mailto: link is simple and appropriate when users are expected to compose the message in their own email application. A contact form is more appropriate when the website needs to control processing, validation, storage or delivery.

Advantages of mailto: Links

• Very easy to implement.
• Requires no email-sending backend.
• Works naturally with configured email applications.
• Can prefill recipients and subjects.
• Can prefill a message body.
• Useful for simple contact and support links.

Limitations of mailto: Links

• The user needs a compatible email handler.
• Behavior depends on browser and operating-system configuration.
• The website cannot guarantee that the email will be sent.
• The website cannot directly track delivery.
• Long message bodies can produce unwieldy URLs.
• Email addresses remain visible in the page source and link destination.
• A mail client or webmail service must handle the request.

The Email Client Problem

A mailto: link relies on the user's environment. Some desktop users have a mail application configured, while others primarily use webmail. Browsers and operating systems can provide different ways to associate mailto: links with an application or web service.

If no appropriate handler is configured, clicking a mailto: link may produce an error, do nothing useful or ask the user to configure an application.

Accessibility and mailto: Links

A mailto: link should communicate its purpose clearly. Avoid relying on an unexplained icon alone, especially when the action is important to the page.

<a href="mailto:[email protected]">
  Email support
</a>

Descriptive link text helps users understand what will happen when they activate the link. It also provides useful context for assistive technologies.

Using an Email Icon

An email icon can accompany a mailto: link, but the accessible name should still clearly identify the action.

<a href="mailto:[email protected]" aria-label="Email support">
  <span aria-hidden="true">✉</span>
</a>

The exact implementation can vary depending on the icon library. The important principle is that users should be able to understand the link's purpose without relying solely on the visual icon.

Security Considerations

mailto: links are not a secure email transport mechanism. They simply provide data to the user's email handler. The recipient address, subject and any prefilled content are visible in the link itself.

This means a mailto: URI should not be treated as a place to hide secrets, authentication tokens or other sensitive information.

Email Address Exposure

A traditional mailto: link contains the email address in the HTML href attribute. This means the address is available to users and can also be collected by automated crawlers that inspect web pages.

If publishing an email address publicly creates an unacceptable amount of spam, consider alternatives such as a contact form or an appropriate email-obfuscation strategy. No client-side obfuscation method should be treated as a guaranteed protection against determined extraction.

Do mailto: Links Cause Spam?

A publicly visible email address can potentially be collected by automated software. The risk depends on how the address is published and which systems scan the page.

Using a mailto: link makes the address part of the link destination, so it should be considered public information. If the address is intended to be private, it should not be embedded into a public page simply because the visible text is hidden behind a button.

mailto: Links and SEO

A mailto: link is primarily a user interaction rather than a normal web navigation link. It does not replace an ordinary webpage URL and should not be used when the goal is to provide search engines with a crawlable page.

For contact information, a website can provide a dedicated contact page and use mailto: as one of the available actions on that page.

Common mailto: Mistakes

Using Spaces Without Encoding

Subjects and message bodies commonly contain spaces. Constructing a URI with raw spaces can lead to inconsistent behavior, so generated parameter values should be properly percent-encoded.

Forgetting to Encode an Ampersand

An ampersand separates query parameters. If the body contains a literal ampersand and it is not encoded, the URI can be interpreted incorrectly.

mailto:[email protected]?subject=Order&body=Product%20A%20%26%20Product%20B

Encoding the Entire URI

Encoding the complete mailto: URI instead of individual dynamic values can transform the URI's structural characters into encoded data. Build the structure first and encode values separately.

Putting HTML Into the Body

A mailto: body is text that is passed to the email handler. It should not be treated as a reliable way to construct an HTML email. Different email applications can interpret or display the prepared body differently.

Making the mailto: URL Too Long

Long prefilled messages create long URLs. Very large mailto: URIs can become inconvenient and may encounter limitations in browsers, applications or operating systems.

Including Sensitive Information in the Subject

The subject is part of the URI and can therefore be visible before the email is sent. Do not put secrets or unnecessarily sensitive information into a prefilled subject.

Testing mailto: Links

Testing a mailto: link requires more than checking that the href looks correct. The final behavior depends on the browser, operating system and configured mail handler.

• Click the link on the primary desktop environment.
• Test it on a mobile device if mobile users are important.
• Check the recipient.
• Check the subject.
• Check the message body.
• Test multiline text.
• Test special characters.
• Test multiple recipients when used.
• Verify that the final message remains editable before sending.

Testing Special Characters

A good test suite should include subjects and bodies containing punctuation, ampersands, question marks, percent signs, accented characters and line breaks.

const subject = "Order #123 & support";
const body = [
  "Hello,",
  "",
  "I have a question about order #123.",
  "The product is called A & B.",
].join("\n");

const href =
  `mailto:[email protected]?subject=${encodeURIComponent(subject)}&body=${encodeURIComponent(body)}`;

console.log(href);

mailto: Links in Buttons

A mailto: link can be styled to look like a button while remaining an ordinary anchor element. This is preferable to using a non-semantic element with a click handler for a simple navigation-style action.

<a
  href="mailto:[email protected]?subject=Support%20Request"
  class="button"
>
  Contact support
</a>

The visual appearance can be controlled with CSS while preserving the link's native semantics and keyboard behavior.

mailto: Links in Markdown

Many Markdown environments support mailto: links through standard link syntax.

[Contact support](mailto:[email protected]?subject=Support%20Request)

Whether a particular Markdown platform permits or sanitizes mailto: links depends on that platform's security and rendering rules.

Generating mailto: Links Programmatically

A small helper function can make mailto: generation consistent across an application.

type MailtoOptions = {
  to: string;
  subject?: string;
  body?: string;
  cc?: string;
  bcc?: string;
};

export function createMailto({
  to,
  subject,
  body,
  cc,
  bcc,
}: MailtoOptions) {
  const params = new URLSearchParams();

  if (subject) {
    params.set("subject", subject);
  }

  if (body) {
    params.set("body", body);
  }

  if (cc) {
    params.set("cc", cc);
  }

  if (bcc) {
    params.set("bcc", bcc);
  }

  const query = params.toString();

  return query
    ? `mailto:${to}?${query}`
    : `mailto:${to}`;
}

This approach keeps the parameter construction in one place and lets URLSearchParams handle the encoding of query values. In a production application, additional validation may be appropriate depending on where the addresses and message content come from.

Validating Email Addresses Before Generating a Link

If an application accepts a recipient from user input, basic validation can help prevent obviously malformed addresses from being placed into the link. Validation should not attempt to prove that an address actually exists.

Email-address syntax has many details, and overly restrictive regular expressions can reject legitimate addresses. For most UI workflows, a sensible validation strategy is preferable to attempting to implement the entire email-address specification with one complex regex.

mailto: Links for Support Pages

A support page is a common place to use mailto:. The link can prepare a recipient and a short subject while leaving the user responsible for writing the actual message.

<a
  href="mailto:[email protected]?subject=Support%20Request"
>
  Email support
</a>

If the support workflow needs attachments, structured fields, automatic ticket creation or guaranteed delivery, a dedicated support form or ticketing system is usually more appropriate.

mailto: Links for Feedback

A feedback link can prefill a subject such as Website Feedback while leaving the body empty.

<a href="mailto:[email protected]?subject=Website%20Feedback">
  Send feedback
</a>

This provides a low-friction way to start a conversation without requiring a backend form.

mailto: Links for Bug Reports

A bug-report mailto: link can prefill a subject and a small template in the body.

mailto:[email protected]?subject=Bug%20Report&body=Environment%3A%0A%0ASteps%20to%20reproduce%3A%0A%0AExpected%20result%3A%0A%0AActual%20result%3A

This can be convenient for small projects. For larger applications, issue trackers and dedicated forms provide better structure and processing.

mailto: Links and Attachments

A mailto: URI does not provide a portable mechanism for attaching arbitrary local files. The email application may support attachments through its own interface, but a website cannot reliably force a local file to be attached through a standard mailto: link.

When Should You Use mailto:?

• Simple contact links.
• Personal websites.
• Small project support links.
• Email links in documentation.
• Prefilled feedback messages.
• Simple business contact pages.
• Situations where users should compose the message themselves.

When Should You Use a Contact Form Instead?

• The website must process submissions automatically.
• You need server-side validation.
• You need spam protection.
• You need guaranteed application-level processing.
• You need file uploads.
• You need structured fields.
• You need analytics or submission tracking.
• You do not want to depend on the user's email application.

A Practical mailto: Checklist

• Use a valid mailto: URI.
• Keep the recipient outside the query string.
• Encode subject and body values.
• Encode ampersands and other reserved characters inside parameter values.
• Use line breaks carefully in multiline bodies.
• Keep prefilled content reasonably short.
• Do not put secrets in the URI.
• Make the link purpose clear to users.
• Test on the browsers and devices that matter.
• Provide an alternative contact method when email-handler availability cannot be assumed.

Frequently Asked Questions

Helpful Email Tools

A Mailto Link Generator can build a mailto: URI from a recipient, subject, body and other supported parameters while handling URL encoding. An Email Address Validator can help check user-entered addresses before they are inserted into generated links.

For other email-related workflows, an Email Header Analyzer is useful when inspecting message headers, while an Email Obfuscator can help reduce straightforward exposure of public addresses in certain website implementations. A QR Email Generator can turn an email action into a scannable QR code for printed materials and offline interfaces.

Conclusion

mailto: links are one of the simplest ways to add email functionality to a website. A basic link can contain only a recipient, while more advanced links can prefill a subject, message body, CC recipients and BCC recipients.

The key technical detail is correct URI encoding. Dynamic subjects, message bodies and other parameter values should be encoded individually so that spaces, ampersands, line breaks and other special characters are treated as data rather than URI syntax.

mailto: is best suited to situations where the user should compose an email using their own email application. It does not provide server-side sending, delivery tracking, guaranteed processing or reliable attachment handling. When an application needs those capabilities, a contact form or email API is a better fit.

Finally, remember that everything inside a mailto: URI should be considered visible client-side data. Keep prefilled content short, avoid sensitive information, make the link accessible and test it across the browsers, devices and email handlers that your audience actually uses.