Mailto Links in HTML: Subject, Body, CC and Encoding

The basic mailto link

Put mailto: and the address in the href of an ordinary link. Nothing else is needed:

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

Showing the address itself as the link text is a good default: a reader whose device opens the wrong app, or no app, can still copy it. For wording link text that makes sense out of context, see the email accessibility guide.

Recipients, subject, body, cc and bcc

RFC 6068 defines the whole scheme in one line: mailto:, then optional addresses, then optional fields. Several addresses go before the fields, separated by commas. The fields start after a single ? and are joined by &, each one written as name=value.

<a href="mailto:support@example.com,billing@example.com?cc=manager@example.com&amp;bcc=archive@example.com&amp;subject=Order%20%2312345&amp;body=Hi%2C%0D%0A%0D%0AI%20have%20a%20question%20about%20my%20order.">
  Email support about order #12345
</a>

• Only one question mark. RFC 6068 lists ?cc=bob@example.com?body=hello as wrong. Every field after the first is joined with &.
• Write & as & in HTML. The RFC says a mailto URI containing an ampersand has to be written with an HTML entity inside HTML. The browser or mail client reads & back as &.
• One field name, once. The RFC says creators should not repeat a field name in the same link. To copy two people, put both addresses in one cc value, comma separated, since the Cc header takes an address list.
• Addresses before the question mark. mailto:?to=a@example.com is valid, but the RFC does not recommend it because different mail apps handle it differently.
• Bcc is not secret in the link. The recipients will not see a bcc address, but anyone who reads the link does. RFC 6068 warns that bcc addresses can leak this way.

Copy-paste examples

Each value below is already encoded. Paste it into an href, and replace every & with & if it goes into HTML source.

A bare mailto: with no address is valid too. MDN notes that it opens an empty draft, which is how a "share by email" link works: the reader picks the recipient.

Percent-encoding the values

Field values are URI text, so any character that has a meaning in the link has to be escaped when it is part of a value. These are the ones that break mailto links in practice:

The space is the one most often wrong. RFC 6068 says spaces should be %20 and notes that encoding them as + causes problems, because + is a legal character in addresses such as bill+ietf@example.org. Form encoding uses + for spaces, so a link built with a form or query-string helper can arrive with plus signs in the subject.

In JavaScript, encodeURIComponent() produces the right result: it escapes everything except letters, digits and - _ . ! ~ * ' ( ), and writes a space as %20. Encode each value on its own, never the whole link, or the ? and & separators get escaped too.

const href =
  "mailto:support@example.com" +
  "?subject=" + encodeURIComponent("Order #12345") +
  "&body=" + encodeURIComponent("Hi,\r\n\r\nI have a question.");

// mailto:support@example.com?subject=Order%20%2312345
//   &body=Hi%2C%0D%0A%0D%0AI%20have%20a%20question.

What the body can and cannot hold

RFC 6068 describes the body field as the content of the first plain-text part of the message, meant for short text messages, not general MIME bodies. So there is no HTML, no formatting and no attachment: only text, with line breaks written as %0D%0A. The RFC allows a mail app to add a final line break of its own. Non-ASCII text is encoded as UTF-8 first, then percent-encoded, so café becomes caf%C3%A9.

The RFC sets no length limit. Keep the body to a sentence or two anyway: it is a starting point the reader edits, and a long encoded body makes the link hard to check by eye.

The RFC also limits what a link can do. A mail app should not send anything without showing the message to the user first, must ignore fields such as From and Date, and should treat unknown header fields as suspect. Subject, keywords and body are the fields the RFC calls safe in general; cc and bcc are widely used, as MDN's own example shows.

Mailto in a web page and in an email

The markup is the same in both. What happens on click depends on the reader's device, not on your HTML: the link goes to whichever app is registered for mailto:. Apple says Mail is the default on a Mac and can be swapped for another email app in Mail's settings (which first needs Mail set up with an account) or in the other app's own settings. On iPhone and iPad the default for links to send email is set under Settings, Apps, Default Apps. A webmail site can also ask the browser to handle mailto: links through registerProtocolHandler(), after which a click opens that site with the address passed along.

None of the sources say what a reader with no mail app at all sees, and it differs by device, so do not depend on the click. Keep the address visible in the link text or next to it.

On a public page, RFC 6068 notes that mailto links expose addresses to harvesting. That covers the browser version of a newsletter too, since it is a public web page. In an email, the more common problem is the opposite: some clients turn plain addresses, phone numbers and dates into links you did not write. Email rendering bugs covers why that happens and how to stop it.

If the mailto link is your main call to action, style it as a button that holds up in Outlook with the bulletproof button generator. Before sending, run the template through the email link checker to catch broken or malformed links, mailto included.

tel: and sms: links

Phone and text links follow the same pattern with their own RFCs. A tel: number should be in global form with a leading + (RFC 3966); hyphens, dots and parentheses are allowed as separators, spaces are not. An sms: link takes one or more numbers separated by commas and an optional body in percent-encoded UTF-8 (RFC 5724).

<a href="tel:+1-201-555-0123">+1 201 555 0123</a>
<a href="sms:+15105550101?body=hello%20there">Text us</a>

MDN notes that tel: behaviour varies by device: phones dial, computers may hand the number to a calling app, and some devices offer to save or send it elsewhere.