Create a link that opens a ready-to-send email with the address, subject and message already filled in. Copy it as a URL, an HTML link, a button or Markdown.
Start from a template
Button style
Recent links
Your mailto link
No email app opened? Your device has no default email app for mailto links, or this page blocks them. Open the same message in webmail instead:
This mailto link generator builds a link that opens the visitor's email app with a new message already addressed and filled in. Add one or more recipients, a subject and a message, and the tool encodes every character so spaces, line breaks and symbols arrive intact, following the mailto standard (RFC 6068).
You can also paste an existing mailto link to edit it, style the link as a button or hide the address from simple spam bots. Everything runs in your browser, and nothing you type is sent to a server. Hiding an address only stops the simplest bots, so pair it with the spam prevention tactics you use on your forms.
Need a form instead of an email link? The contact form generator or the more flexible HTML form generator builds one in minutes from ready-made contact form templates, and on WordPress IvyForms stores every entry for you.
A mailto link generator is a web form tool that builds a percent-encoded mailto: URI from recipient, cc, bcc, subject and body inputs, so nobody writes the encoding by hand.
Most versions also wrap the result in a ready-to-paste HTML anchor.
The output usually comes in 3 forms:
The encoding is the real value. An ampersand typed into a subject starts a new field, and a raw space or line break is not valid inside a URI.
The format comes from RFC 6068 (IETF, October 2010), which replaced RFC 2368 from July 1998. Its IANA registration template lists the mailto scheme as permanent.
Clicking does not send the email by itself. The mail client opens a draft, and the person decides whether to edit it, send it or close it (RFC 6068, section 3).
A mailto link is the scheme mailto: plus one or more addresses, then a ? before the first header field and an & before each later one. Everything after the address is optional.
| Field | Position | Multiple values | Client support |
|---|---|---|---|
| to | After mailto:, before ? | Yes, comma-separated | Read as the address |
| cc | ?cc= or &cc= | Yes, comma-separated | Not guaranteed |
| bcc | ?bcc= or &bcc= | Yes, comma-separated | Not guaranteed |
| subject | ?subject= or &subject= | No | Required of clients |
| body | ?body= or &body= | No | Required of clients |
RFC 6068 says the creator of a link cannot expect a client to understand more than subject and body. Clients must build valid messages from those two, so cc and bcc depend on the mail app.
Fields such as From and Date placed in the URI must be ignored by the client (section 3).
Generators differ on coverage too. Some expose only address, subject and body, while others add cc and bcc (checked October 2026).
One ? opens the field list. Every field after the first needs its own &.
Correct: mailto:[email protected][email protected]&body=hello
Wrong: mailto:[email protected][email protected]?body=hello
Both examples come from RFC 6068, section 6.1, which marks the second one as incorrect.
Separate addresses with a comma and no space after it. The RFC grammar is one address followed by any number of comma-plus-address pairs.
Several how-to pages, including a freeCodeCamp tutorial, show a space after the comma and raw spaces in the subject. RFC 6068 allows neither, and a generator removes both.
Failure mode: repeating the same field name makes clients behave differently. Some keep the first value, some the last, some merge them and some create several header fields (RFC 6068, section 2). Repeated addresses may simply be dropped, so list each one once (section 3).
Three documents define the format.
RFC 6068 also dropped the old ban on Bcc fields and added a warning that bcc addresses are visible in the URI to anyone who scrapes the page.
Replace each space with %20, each line break with %0D%0A, and each reserved character with its percent code. For non-ASCII text, encode as UTF-8 first, then percent-encode every byte.
A generator does all of this from plain text.
| Character | Encoded form | Why it needs encoding |
|---|---|---|
| Space | %20 | Not valid in a URI, and RFC 6068 prefers %20 over + |
| Line break | %0D%0A | The sequence RFC 6068 requires in the body |
| Ampersand | %26 | Splits fields when left raw |
| Hash | %23 | Fragments mean nothing in a mailto URI |
| Percent sign | %25 | Starts every percent code, so a literal one needs escaping |
The question mark and equals sign follow the same rule: %3F and %3D whenever they are not acting as delimiters.
Every new line in the body is %0D%0A. A bare %0A is not what the RFC specifies.
RFC 6068, section 6.1, shows a two-line request as body=send%20current-issue%0D%0Asend%20index.
Some published examples use %0A alone, which departs from the RFC wording. A generator that outputs %0D%0A matches the standard.
Limit: line breaks belong in the body only. The RFC says to avoid them in every other header field.
JavaScript's encodeURIComponent() is the usual tool for subject, body and cc values.
Every character it leaves untouched is also legal inside an RFC 6068 header value, so its output drops safely in after cc=, subject= or body=.
Replace each line feed with a carriage return plus line feed before encoding, otherwise a typed line break comes out as %0A.
Failure modes: encoding an already encoded value turns every % into %25, so encode each value once. A lone surrogate in the input throws a URIError. And the address part should keep its @ and commas literal, because encoding them no longer matches the address grammar.
Non-ASCII characters become UTF-8 bytes, each written as a percent code. RFC 6068 (section 6.3) shows a French subject with an accented e as subject=caf%C3%A9.
The RFC's own registration template adds that interoperability for UTF-8 percent-encoded mailto URIs might be somewhat lower than for plain US-ASCII.
A percent sign inside an address becomes %25, so gorby%[email protected] is written gorby%[email protected].
Ampersand in an address, original text: RFC 6068 section 6.1 writes Mike&[email protected] as mailto:Mike%[email protected].
Ampersand in an address, verified erratum 7919 (2024): the fix to section 2 removes the rule that &, ; and = must be percent-encoded in addresses. Its notes call Mike&[email protected] unambiguous in the address part, while %26 stays required inside header values such as the body. The section 6.1 example itself was left unchanged.
Encoding the ampersand as %26 everywhere is valid under both readings, so that is the safe output for a generator.
Enter the recipient, add cc, bcc, subject and body as needed, copy the generated link or anchor, then test it in a mail app. Six steps, and only the recipient is required.
Step 6 is the one people skip. Support beyond subject and body varies by client, so a missing cc or bcc in the draft is the first thing to look for.
Inputs: recipient [email protected], cc [email protected], subject "Order 4821 support request", and a two-line body ("Hi team," then "My order has not arrived.").
| Field | Written by hand | encodeURIComponent output |
|---|---|---|
| cc | [email protected] | cc=manager%40example.com |
| subject | subject=Order%204821%20support%20request | subject=Order%204821%20support%20request |
| body | body=Hi%20team,%0D%0AMy%20order%20has%20not%20arrived. | body=Hi%20team%2C%0D%0AMy%20order%20has%20not%20arrived. |
Both versions open the same draft, because clients must decode percent codes before building the message (RFC 6068, section 5). The hand-built link is shorter and easier to read.
The fully encoded one is the safer choice when the values come from user input.
Copy the raw link when a tool asks for a URL, the HTML anchor when you control the page markup, and an anchor styled as a button for a call to action. All three carry the same mailto URI underneath.
Failure mode: never nest a button element inside the anchor. The HTML Standard bars interactive content inside an a element, so a nested button is invalid markup.
Inside the href attribute, write each ampersand as &. RFC 6068 (section 6.1) shows the pattern: href="mailto:[email protected][email protected]&body=hello".
The visible link text can say anything, which is the point of the anchor. Write what the click does ("Email support") instead of printing the address a second time.
Because text and href can differ, RFC 6068 (section 7) tells clients to show the full decoded draft and ask for approval before anything goes out.
A mailto link opens whichever app the system or browser has registered for the mailto scheme. If none is registered, or the registered one is a webmail tab the reader is signed out of, the click opens the wrong app or nothing.
Apple's support documentation says a Mac user can pick a browser as the default email reader, but the browser might not open webmail on its own.
On a shared machine, a click can do nothing at all.
| Client | Where the default is set | Catch |
|---|---|---|
| Apple Mail | Mail menu, Settings, General tab, Default email reader | Mail needs an email account set up first, though you can remove it afterwards |
| Mozilla Thunderbird | Default check at startup, or Check Now in its settings | Other apps may need a restart, and Firefox on KDE Linux ignores OS defaults |
| Gmail in Chrome | Protocol handler icon in the address bar | Safari needs a third-party app or extension |
Webmail registers itself with the registerProtocolHandler() browser API, which the HTML Standard defines under custom handlers.
MDN's example registers https://mail.example.org/?to=%s. After that, a click on any mailto link navigates to that address with the mailto URI inserted (MDN Web Docs, page updated June 2025).
Limit: MDN lists the API as limited availability and not Baseline, so some widely used browsers do not support it.
Work from the link outward.
Link: one ? before the first field and an & before every later one.
Encoding: no raw spaces, ampersands or line breaks left in the subject or body.
Handler: a default mail app exists, and it is the one the reader expects.
One more cause looks like a bug but is allowed behavior. RFC 6068 (section 4) says a client should not build a message when it considers a header field dangerous, and may build one with only a subset of the fields.
A mailto link is the wrong choice for high-volume or public contact points, long pre-filled messages, and readers without a configured mail app. Keep it for a single low-volume address and use a form for everything else.
| Option | Needs a mail app | Address in page source | Best use |
|---|---|---|---|
| Mailto link | Yes, the registered default | Yes | One low-volume contact address |
| Contact form | No | No, it stays on the server | Public pages, high volume |
| Gmail compose URL | No, but a Gmail sign-in | Yes, inside the URL | Audiences known to use Gmail |
| Outlook on the web deep link | No, but a Microsoft sign-in | Yes, inside the URL | Audiences known to use Outlook on the web |
RFC 6068 sets no maximum length for a mailto URI.
Vendor rule of thumb: generator vendors commonly put the safe practical ceiling at roughly 2,000 characters and note that older Outlook versions truncate well before browsers do.
Client documentation: Microsoft lists 2084 characters as Outlook's URL limit, raised to 8192 in desktop build 16116.10000 (Microsoft Support, updated November 2023).
The two figures measure different things. The vendor figure is a cautious rule of thumb, and Microsoft's number covers links in general, not mailto bodies specifically.
Design to 2,000 characters and move anything longer into a form. If you swap a mailto link for a form, the form conversion rate calculator shows whether the change paid off.
More than 43% of email addresses placed on web pages were later abused for spam, against about 4% of addresses used for newsletter subscriptions (Schryen, Computers & Security, 2007).
The data is from 2007, so read the size as dated and the direction as the point.
Three ways to reduce the exposure:
Gmail and Outlook on the web both accept compose links, but only for readers who use that service.
Willison also reports that a Gmail compose link opened in Mobile Safari lands on the inbox instead of the compose window.
Both patterns come from developer notes and community threads, so treat them as unstable. A mailto link keeps working across clients, which is why it stays the default for a general audience.
If a form is the better fit, you can see how other sites lay out their contact forms before building one.
Want every message, even from visitors without an email app?
IvyForms gives WordPress sites a contact form that saves each entry, filters spam and emails you instantly, all without code.
Add the recipient, then an optional subject, message, CC and BCC, or start from a template.
Click the preview or "Test in my email app" to see exactly what visitors will get.
Copy the raw URL, an HTML link, a styled button or Markdown, whichever your site or editor needs.
No. The mailto standard has no field for attachments, so the visitor has to attach files in their email app. Mention the file in the message text if you expect one.
Yes. Open "Edit an existing mailto link", paste the link and click "Load into the editor". The recipients, subject and message are decoded into the fields so you can change them and copy a clean version.
Yes. Pick a color, size, corner radius and icon under Button style, then copy the Button tab. You get a link with a class plus a small style block, with no extra scripts.
No. The generator runs entirely in your browser. Your last link and the five most recent links you copied are remembered on this device for convenience and are never sent to a server.