What Are Mailto Links and How Do They Work?

If you've ever clicked a "Contact Us" link on a website and saw your email app pop open with an address already filled in, you've actually used a mailto link. They have been part of the web since the early 1990s, and they're still one of the quickest (though not the cleanest) ways to connect website visitors with a real inbox.

This guide covers everything you need to implement mailto links properly, from basic syntax and parameter customization to URL encoding, practical use cases, common pitfalls, and when a contact form might serve you better.

What Is a Mailto Link?

A mailto link is an HTML hyperlink that opens the user's default email client instead of navigating to another web page. When someone clicks it, their device launches whatever email app is registered within the system as the default, such as Outlook, Apple Mail, or Gmail, and creates a new draft with the recipient address already filled in.

The link itself is built using a standard HTML anchor tag (<a>) with the mailto: scheme in the href value:

<a href="mailto:support@example.com">Email our support team</a>

When a visitor clicks "Email our support team", their email client opens a new message addressed to support@example.com. That's it. You do not need to set up any backend processing, form validation, or server-side code. 

The browser recognizes the mailto: protocol and hands it off to the operating system which routes it to the default mail application. This simplicity is what makes mailto links useful, however it's also coupled with their inherent limitations (more on that later).

Basic Mailto Link Syntax

Every mailto link follows the same structure. You place the mailto: scheme inside the href attribute of an anchor element:

<a href="mailto:info@yourcompany.com">Get in touch</a>

A few things to note here:

• There is no space between mailto: and the email address
• The anchor text ("Get in touch") is what users see and click on
• The email address is not enclosed in angle brackets or extra quotes inside the href

Sending to Multiple Recipients

You can address the email to more than one person by separating addresses with a comma:

<a href="mailto:sales@example.com,support@example.com">Contact our team</a>

This opens a new email with both addresses in the "To" field. Keep in mind that all recipients will be visible to each other.

Customizing Mailto Links with Parameters

A plain mailto link fills in the "To" field and nothing else. But you can pre-populate other fields by appending query parameters to the href value.

The first parameter is separated from the email address with a question mark (?). Any additional parameters after the first one are joined with an ampersand (&).

Adding a Subject Line

To pre-fill the subject field, add the subject parameter after the email address. Since this is the first parameter being added, use ? to separate it from the address. Spaces in the subject text need to be encoded as %20. Many other characters need to be encoded as well, more on that later. 

<a href="mailto:support@example.com?subject=Account%20Issue">   Report an account issue </a>

This opens a new email to support@example.com with the words "Account Issue" already in the subject line. Pre-filled subject lines are useful for organizing incoming messages. Your team can filter or sort by subject without relying on the sender to write one. Note, however, that this method may be unreliable: the user can delete your pre-filled subject and write an entirely new one.

Adding Body Text

To pre-populate the email body, use the body parameter. Since body is unlikely to be the first parameter, separate it with &. Line breaks inside the body text must be encoded as %0D%0A, and commas as %2C.

<a href="mailto:support@example.com?subject=Account%20Issue&body=Hi%2C%20I%20need%20help%20with%20my%20account.">   Report an account issue </a>

This opens a draft with both the subject and body pre-filled. Keep prefilled body text short but make sure the user understands they can easily edit it. Nobody wants to send a message they didn't write.

Adding CC and BCC

To copy other recipients on the email, use the cc parameter for visible copies and bcc for hidden (blind) copies. Both follow the same & separator as any additional parameter after the first.

<a href="mailto:support@example.com?cc=manager@example.com&bcc=logs@example.com">   Contact support </a>

In this example, manager@example.com receives a copy and is visible to all parties, while logs@example.com receives a copy without anyone else knowing.

Skipping the "To" Field

There are situations where you don't want the email addressed to you at all. Maybe you're running a referral campaign and want visitors to share something with their own contacts, or you want users to forward a link to a colleague. In those cases, you can leave the recipient blank and only pre-fill the subject and body.

To do this, leave nothing between mailto: and the ? that starts your parameters:

<a href="mailto:?subject=Check%20this%20out&body=I%20thought%20you%20might%20find%20this%20interesting%3A%20https%3A%2F%2Fexample.com%2Foffer">   Share this with a friend </a>

This opens the user's email client with the "To" field empty, letting them fill in whatever address they want. The subject and body are already populated.

One caveat to keep in mind, this approach is not fully reliable across every email client. Most modern desktop and webmail clients handle it fine, but some older or less common clients may not open the compose window at all when no recipient is provided. Test it on the clients your audience is most likely to use before relying on it.

Opening in a New Tab

By default, clicking a mailto link hands the request off to the user's operating system, which routes it to their default email application. If that application is a desktop client like Outlook or Apple Mail, it opens as a separate window regardless of any HTML attributes you add; the browser isn't involved at that point.

Where target="_blank" can make a difference is when the user has a web-based email client (like Gmail) configured as their default mailto handler. Here, adding target="_blank" tells the browser to open the webmail compose window in a new tab, while keeping the user on your site in the original tab:

<a href="mailto:info@example.com" target="_blank" rel="noopener noreferrer">   Send us an email </a>

Without target="_blank", the browser would load the webmail client in the same tab, taking the user away from your page.

However, the behavior is inconsistent across browsers; for instance, Chrome generally respects it when Gmail is the registered mailto handler, but Firefox has a long-standing bug where it ignores the attribute entirely, and Safari may show a confirmation dialog before allowing the action. 

Because of these inconsistencies, target="_blank" on mailto links isn't something you can rely on. Leaving it out and accepting the default behavior is the simpler and more predictable choice.

URL Encoding in Mailto Links

If you've noticed %20 and %0D%0A scattered through the examples above, that's URL encoding (also called percent-encoding). URLs can only safely contain a limited set of characters. Anything outside that set, like spaces, line breaks, and special punctuation, needs to be converted into a special encoded format so browsers and email clients interpret the link correctly.

Here are the most common characters you'll need to encode in mailto links:

Character	Encoded Value	Usage
Space	%20	Separating words in subject and body
Line break	%0D%0A	Starting a new line in the body
Comma	%2C	Do not use when separating recipients
Ampersand	%26	Literal & inside subject or body text
Equals sign	%3D	Literal = inside parameter values
Question mark	%3F	Literal ? inside parameter values
Forward slash	%2F	Including URLs inside the body

An important note: encode the parameter values (subject text, body text), not the parameter names or the structural characters (?, &, =) that connect them. The protocol (mailto:) and the email address itself should also stay unencoded.

Modern browsers can handle unencoded spaces correctly, but encoding them as %20 prevents inconsistent behavior across different browsers and email clients. It takes an extra minute and saves you from debugging later.

Encoding every space and line break manually looks like a chore? It really is. Tools like mailtolink.me and htmlstrip.com/mailto-generator let you fill in the recipient, subject, body, CC, and BCC fields through a simple form, and they generate the fully encoded mailto link for you. Worth bookmarking if you're creating more than one or two links.

Mailto Syntax Cheat Sheet

Here's a quick reference you can come back to when building mailto links:

• Basic link: mailto:email@example.com
• With subject: mailto:email@example.com?subject=Your%20Subject
• With body: mailto:email@example.com?body=Your%20message%20here
• With CC: mailto:email@example.com?cc=other@example.com
• With BCC: mailto:email@example.com?bcc=hidden@example.com
• Multiple recipients: mailto:one@example.com,two@example.com
• Line break in body: Use %0D%0A
• All combined: mailto:email@example.com?subject=Hello&cc=copy@example.com&bcc=blind@example.com&body=First%20line%0D%0ASecond%20line

Practical Mailto Link Examples for Real Business Use

Generic examples only get you so far. Here are mailto links built for actual business scenarios you can adapt and use on your own site.

Customer Support Request

If your support team keeps getting emails with no order number or description of the issue, you can solve that by pre-filling the body with a simple template that prompts the customer to include the right details.

<a href="mailto:support@example.com?subject=Support%20Request%20-%20Order%20%23&body=Hi%20Support%2C%0D%0A%0D%0AMy%20order%20number%20is%3A%20%0D%0AThe%20issue%20I%20am%20experiencing%3A%20%0D%0A%0D%0AThank%20you">   Submit a support request </a>

This opens a draft with a structured body that guides the customer through filling in their order number and describing the problem. It saves your support team from chasing basic details in follow-up emails.

Demo Booking

For sales teams, the first email from a prospect often lacks the context needed to prepare for a conversation. A mailto link that prompts for company name, preferred timing, and team size captures that information upfront.

<a href="mailto:sales@example.com?subject=Demo%20Request%20-%20%5BCompany%20Name%5D&body=Hi%2C%0D%0A%0D%0AI%20would%20like%20to%20schedule%20a%20demo.%0D%0A%0D%0ACompany%3A%20%0D%0APreferred%20date%2Ftime%3A%20%0D%0ATeam%20size%3A%20%0D%0A%0D%0ALooking%20forward%20to%20hearing%20from%20you.">   Book a product demo </a>

Pre-filling these fields gives your sales team useful context before they even reply, and it signals to the prospect that you'll be prepared for the call.

Bug Report

Documentation sites and landing pages don't always justify a full-blown issue tracker. A mailto link with a structured bug report template gives users a low-friction way to flag problems while still collecting the information your engineering team needs.

<a href="mailto:bugs@example.com?subject=Bug%20Report%20-%20%5BFeature%20Name%5D&body=Steps%20to%20reproduce%3A%0D%0A1.%20%0D%0A2.%20%0D%0A3.%20%0D%0A%0D%0AExpected%20behavior%3A%20%0D%0AActual%20behavior%3A%20%0D%0ABrowser%2FDevice%3A%20">   Report a bug </a>

The prefilled body walks the user through the standard steps-to-reproduce format, expected vs. actual behavior, and browser or device information, the same fields most issue trackers ask for, without requiring the user to create an account.

Press or Media Inquiry

Journalists typically reach out with a specific angle and a tight deadline. A mailto link that prompts for publication name, topic, and deadline upfront shows that your team understands how press workflows operate.

<a href="mailto:press@example.com?subject=Media%20Inquiry%20-%20%5BPublication%20Name%5D&body=Hi%2C%0D%0A%0D%0AI%20am%20a%20journalist%20with%20%5BPublication%5D%20and%20would%20like%20to%20inquire%20about%3A%0D%0A%0D%0ADeadline%3A%20%0D%0AContact%20number%3A%20">   Press inquiries </a>

Including the deadline field is especially important here. It tells journalists you take timely responses seriously, and it helps your PR team prioritize incoming requests.

Product Question

Sometimes a visitor just has a quick question about a specific product and doesn't need a full support workflow. A lightweight mailto link with the product name in the subject line and an open-ended body keeps things simple for both sides.

<a href="mailto:info@example.com?subject=Question%20About%20%5BProduct%20Name%5D&body=Hi%2C%0D%0A%0D%0AI%20have%20a%20question%20about%20your%20product%3A%0D%0A%0D%0A">   Ask about this product </a>

In every example above, the body text is kept short and editable. The goal is to give the user a starting point and a clear structure, not to put words in their mouth. If the prefilled message is too long or too rigid, people will either delete everything and start from scratch or abandon the email entirely.

Why Mailto Links Sometimes Don't Work

Mailto links are simple, but "simple" doesn't mean unbreakable. Here are the most common reasons a mailto link might fail or act unexpectedly for your users:

 

• No default email client configured: If a user hasn't set up a desktop mail application, clicking a mailto link either does nothing or triggers a system prompt asking them to configure one. Users who rely entirely on web mail (Gmail, Yahoo Mail, Outlook.com) through the browser often don't have a default client registered with their OS. Or worse, a system-default client has nothing to do with what they actually use.
• Browser behavior differences: Chrome, Firefox, Safari, and Edge each handle the mailto: protocol slightly differently. Some browsers let users register a webmail service as the default handler (Chrome, for example, can register Gmail), while others can only pass the link to the system-level default. The same mailto link can produce different results depending on the browser.
• Mobile inconsistencies: On iOS, mailto links generally open the default Mail app, but users who prefer a third-party app like Gmail or Outlook may not have it set as the default. On Android, the OS usually presents a chooser dialog if multiple email apps are installed, which adds a step but at least gives the user a choice.
• Webmail not logged in: Even when a browser is configured to open Gmail for mailto links, the user still needs to be logged in. If they're not, they land on a sign-in page instead of a compose window, and the prefilled fields may or may not carry over after authentication.
• Browser extensions and security settings: Some ad blockers, privacy extensions, or corporate security policies can intercept or block mailto links. This is uncommon, but it happens, especially in enterprise environments with strict network rules.
• Older or niche email clients: Most modern clients handle mailto parameters (subject, body, CC, BCC) without any issues. But some older clients or less common applications may ignore certain parameters or handle URL encoding differently.

None of these issues is within your control as a developer. That's exactly why testing mailto links across different browsers, devices, and operating systems before shipping is important, and why you should always offer an alternative contact method alongside them.

Limitations of Mailto Links

Beyond the compatibility issues above, mailto links have some fundamental constraints worth understanding:

• No file attachments: The mailto protocol does not support attaching files. There is no attachment parameter or anything similar. If you need the user to send a file, include a download URL or upload link in the body text as a workaround. As a better but more complex option, use a contact form with file upload support instead of a mailto link.
• No send confirmation: Clicking a mailto link opens a draft; it doesn't send an email. There is no way to know whether the user actually hit "Send" after the draft opened. If tracking or confirmation matters to your workflow, a server-side contact form with a confirmation receipt is the better choice.
• No click tracking by default: Mailto links themselves don't generate analytics events. You can track clicks with JavaScript event listeners or Google Tag Manager, but you're only tracking the click, not whether the email was composed, edited, or sent.
• Inconsistent user experience: Because mailto depends entirely on the user's device, browser, and mail client configuration, you can't guarantee a consistent experience. One visitor might get a smooth, prefilled draft in Outlook. Another might see an error about missing email software. You're delegating the entire interaction to the user's local setup.
• Harvesting vulnerability: Your email address just lies there in the open, ready for any email-hungry harvesting bot. While modern mailbox providers do an excellent job of filtering spam, your local infrastructure may be far less protected. 

When to Use Mailto Links vs. Contact Forms

This is a decision that comes up on almost every project, and the answer depends on what you're trying to accomplish.

Mailto links work well when you need a fast, no-backend way to let people reach you by email. They're also a good fit when you want the user to keep a copy of their message in their own sent folder. Also great when you don't need structured data like dropdown selections or file uploads.

Contact forms are the stronger choice when you need to collect specific, structured information (name, company, topic, budget range) or when file uploads are part of the workflow. They also give you more control over spam through tools like reCAPTCHA, provide confirmation that the message was actually received, and let you route submissions to different inboxes based on the form fields. 

If your users are primarily on webmail and may not have a default email client set up, a contact form removes that friction entirely. You can also build them natively in WordPress with minimal effort.

For many websites, the strongest approach is using both a contact form as the primary method and a visible mailto link as a fallback for users who prefer composing in their own email client.

Accessibility Tips for Mailto Links

A few adjustments make mailto links more usable for everyone, including people using screen readers or keyboard navigation:

• Make the email address visible in the link text: Anchor text like "Click here" or "Contact us" doesn't tell the user that clicking will open their email client. Use the actual email address as the link text, or clearly state that the link opens an email. This also helps sighted users who want the address but don't want to trigger a mailto action. They can read it and type it manually.

<!-- Preferred --> <a href="mailto:support@example.com">support@example.com</a> <!-- Alternative --> <a href="mailto:support@example.com">Email our support team (support@example.com)</a>

• Never hide the email address behind a generic button: Roughly half of desktop users don't have a default email client configured. If the address is hidden behind a "Contact Us" button that triggers a mailto link, those users see an error and have no way to retrieve the address.
• Add an aria-label when the link text isn't the address itself: If your design uses anchor text like "Email our team," add an ARIA label for screen reader context:

<a href="mailto:support@example.com" aria-label="Send an email to support at example dot com">   Email our team </a>

• Provide an alternative contact method nearby: Not everyone can use mailto links. Place a contact form link, phone number, or messaging option near the mailto link so users have options.

Changing the Default Mailto Behavior

If clicking a mailto link doesn't open the email client you actually use, the fix is usually a quick settings change on your device or browser.

• On Windows 11, open Settings and go to Apps -> Default apps. In the search bar, type "mailto" and select the URL:MailTo Protocol option. From there, choose the email client you want to handle mailto links (Outlook, Thunderbird, or whatever you have installed). If you'd rather use a webmail service like Gmail, set your browser (Chrome or Edge) as the mailto handler here, then configure the browser to route mailto links to Gmail. To do this, navigate to Settings -> Apps -> Default apps. Then, scroll down and select “Choose default apps by protocol”. Search for “mailto”, then, select your preferred default email client.

Now, to configure the browser to route mailto links to Gmail, follow the steps below:

1. Open Chrome (if you chose chrome as the default email client) and type chrome://settings/handlers into your address bar, then press Enter.

2. Ensure the toggle for “Sites can ask to handle protocols” is turned on.
3. Navigate to Gmail in your Chrome browser and log in.
4. Look to the far right of your address bar. Click the Protocol Handler icon (it looks like a double diamond or overlapping cards).
5. When prompted asking if Gmail can open all email links, select Allow, then click Done.

• On macOS (Sonoma and later), open the Mail app. Then, go to Mail -> Settings -> General, and select your preferred email client from the "Default email reader" dropdown. 

If the app you want doesn't appear in the list, make sure it's installed, up to date, and has been opened at least once so macOS can register it as an available handler.

• In Firefox, click the menu button and go to Settings -> General. Scroll down to the Applications section and search for "mailto" in the content type list. Use the dropdown in the Action column to choose your preferred handler, such as Gmail, Yahoo Mail, or a desktop client like Thunderbird.

Best Practices for Mailto Links

To wrap up the implementation side, here are the practices that matter most:

• Use descriptive anchor text: "Email our support team at support@example.com" tells the user exactly what will happen and gives them the address even if they don't click.
• Keep prefilled subjects relevant: A subject line like "Support Request Order Issue" helps your team sort and prioritize incoming messages. A subject like "Hello" does not.
• Keep prefilled body text short: Give users a template, not a script. Two or three prompt lines are enough.
• Always encode your parameter values: Use %20 for spaces, %0D%0A for line breaks, and %2C for literal commas, etc. Don't assume the browser will handle raw characters correctly.
• Test across browsers, devices, and email clients: At minimum, test on Chrome, Firefox, and Safari on desktop, plus the default mail apps on iOS and Android. Make sure that subject, body, CC, and BCC all carry over correctly.
• Always provide an alternative contact method: Whether it's a contact form, a phone number, or a live chat widget, give users a backup. Mailto links will not work for every visitor.
• Don't overuse mailto links on a single page: One or two well-placed links are helpful. A dozen scattered across the page looks unprofessional and increases your spam exposure.
• Be aware of spam harvesting: If bot traffic is a concern, consider JavaScript-based obfuscation to render the email address client-side rather than including it as plain text in the HTML source. This isn't a complete fix, but it blocks the simplest crawlers.

Conclusions

Mailto links remain one of the most straightforward tools for connecting website visitors with an email inbox. They require zero backend infrastructure, work across every major browser and operating system, and can be customized with prefilled subject lines, body text, CC, and BCC using simple query parameters.

That said, they come with real trade-offs. You can't attach files, confirm delivery, track whether the email was actually sent, or guarantee a consistent experience across every device and mail client configuration. Exposed email addresses are also fair game for spam bots unless you take steps to obscure them.

Use mailto links when you need fast, low-friction email contact with minimal setup. Use contact forms when you need structured data, file uploads, spam prevention, or delivery confirmation. On most websites, offering both gives your visitors the best experience.

Related Services

If you found this blog useful, you might also want to explore UniOne's SMTP Service, a scalable email delivery platform that handles both transactional and marketing emails. UniOne offers high throughput, built-in analytics, template management, and a RESTful Email API, making it a strong option for developers and businesses that need more than what a basic hosting email or a simple mailto link can provide.

FAQ

Can I add attachments to a mailto link?

Unfortunately, no. The mailto scheme does not support file attachments. There is no parameter for including files in the link. If you need the recipient to send or receive a file, your best options are to include a download URL in the prefilled email body, or to use an HTML contact form with a file upload field instead.

Why doesn't my mailto link open Gmail?

By default, most operating systems route mailto links to a desktop email application, not a browser-based webmail service. If you want mailto links to open Gmail, you (or your users) need to configure the browser to register Gmail as the default mailto handler. 

Are mailto links safe to use?

Mailto links themselves don't introduce a security vulnerability in the traditional sense. Clicking one doesn't execute code or download files. However, including a plain email address in your HTML source does expose it to spam bots that crawl websites and harvest addresses. 

To reduce this risk, you can use JavaScript-based obfuscation to render the address dynamically or encode it as HTML entities. Neither method is completely foolproof, but they block the most common automated scrapers. 

For websites with high traffic or significant spam concerns, pairing a mailto link with a contact form protected by reCAPTCHA is a more robust approach.

Do mailto links work on mobile devices?

Yes, mailto links work on both iOS and Android. On iOS, tapping a mailto link typically opens the default Mail app. If a user has configured a third-party email app (like Gmail or Outlook) as their default, that app opens instead. 

On Android, the system usually presents a chooser dialog if more than one email app is installed, letting the user pick which app to use. The prefilled fields carry over in most modern email apps on both platforms, though it's always worth testing to confirm.