Also available in: Español · Português · Français · العربية
Mailto Link Generator
Make a mailto link with a subject and body that survives the trip — and see what the usual way of building one would have got wrong.
What is a mailto link?
A mailto link is a URI that opens the reader's own mail program with a message already started. Put one in an href and a click gives them a composed draft rather than an address they have to copy. The simplest form is just an address, and everything after the question mark — subject, body, cc, bcc — is an optional header field.
It sends nothing by itself. The link only opens a draft in whatever mail program the reader has set as their default, and they still have to press send. That is worth knowing before you design around it, because it means the contents are entirely visible and entirely editable by the person clicking.
This generator builds the link, shows it as raw text and as an HTML anchor, and lets you open it to check what your own mail app does with it. It also shows what the same link looks like when it is built the way almost everyone builds it, which is the interesting part.
How to use it
- Fill in the recipient. One address, or several separated by commas. Cc and Bcc work the same way and are optional; the tool notes that the specification treats them differently from the subject and body.
- Write the subject and body. Type them exactly as you want them to appear, including line breaks — the encoding is handled for you. The link rebuilds as you type.
- Copy the link, or open it to test. Copy gives you the URI for an href; the open button hands it to your default mail program so you can confirm it arrives the way you meant.
Why most mailto links are encoded wrong
A mailto link ends in something that looks exactly like a query string, so it gets built like one — with form encoding, the same rules a browser uses when it submits a form. That is the mistake, and it is close to universal because nothing ever errors.
RFC 6068 defines what may appear in one of these fields, and the list does not include the space. It does include the plus sign, as a literal plus sign. So when form encoding turns your space into a plus, it is not writing a shorthand a mail client will decode back — it is writing a character that means itself, and a correct client will show a subject line reading Website+enquiry. Line breaks are the second one: the specification says a break in the body must be written as %0D%0A, and form encoding produces only the second half of that.
Checked across all 128 ASCII characters rather than a sample, form encoding differs from the correct encoding on 14 of them. That count overstates the problem, so it is worth splitting: 11 of the 14 are characters written out at greater length than they needed to be, which is allowed and arrives identically — the apostrophe in a word like I'd is one of these. Only 3 change what the reader actually receives, and those 3 are the space and the two halves of a line break. A small number of characters, and precisely the ones that appear in every subject and every body anybody writes.
There is a practical version of this that costs people real mail. A plus sign is legal in an address, and plus-addressing — the you+shop@example.com trick for filtering — is common. Build the link correctly and the plus survives untouched. Build it with form encoding and the plus is liable to come back as a space, which is not a valid address, and the message bounces.
Honest limitations
The specification is careful about which fields a mail program should honour, and it is more restrictive than practice. Section 4 names only Subject, Keywords and Body as believed both safe and useful in general, and says a client may build the message from only some of the fields it was given. Cc and Bcc are honoured by every mail program worth the name, so this tool offers them — but they are a request rather than a guarantee, and a field like From is one you should expect to be ignored or to cause the message to be refused outright.
Line breaks belong in the body and nowhere else. The specification says they should not be used in other fields, so a break in a subject is flagged here rather than silently encoded; most mail programs will drop or mangle it.
How the draft ends up looking is not fully in your control either. Long bodies get truncated by some clients, a few strip formatting, and webmail set as the system handler behaves differently again from a desktop program. Test the link in the mail app your readers actually use before relying on a long body, and keep anything essential in the visible text of the page rather than inside the link.
Finally, an address written into a page as a mailto link is an address written into a page. Address-harvesting robots read HTML perfectly well, and no amount of encoding changes that — percent-encoding the characters is an encoding rule, not an obfuscation technique, and this tool does not pretend otherwise.
Why is it free?
The link is assembled in your browser. Percent-encoding a string is not work that needs a server, so there is nothing to run and nothing to charge for, and no account to make.
Nothing you type is uploaded, stored or logged, and no message is ever sent from this page — it only ever produces text for you to paste. Addresses and draft messages are exactly the sort of thing that should not travel to somebody else's server to be formatted.