Email QR codes — the underrated business card swap

You print a small QR on a business card, on a leaflet, on the back of a packaging box. Someone scans it. Their phone opens the mail app with your address filled in, the subject line already says "Saw your card at the conference," and the body has a one-line prompt to introduce themselves. They tap send. You've got a real introduction in your inbox before you've shaken anyone's hand.

That's an email QR code, and almost no one uses them properly. Most "business card QR" tutorials default to vCard — the structured contact format that pours your name, phone, address, and photo into the recipient's contacts app. vCard has its place. But for a lot of conference-floor, packaging-insert, and lead-magnet scenarios, what you actually want is a single-purpose mailto link that converts curiosity into a draft email faster than a website ever will.

This post covers the mailto QR format (it's older than QR codes themselves), when it beats a vCard, the special-character traps that silently break the encoding, and the mobile parser quirks that decide whether someone's tap opens Gmail, the system mail app, or nothing at all.

The mailto syntax#

A mailto QR encodes a URL like mailto:hello@example.com?subject=Saw%20your%20card&body=Hi%2C — the same URI scheme that powers email links on every webpage built since 1995. RFC 6068 is the spec. Three things sit inside it:

• The address — the part after mailto: and before the ?. Required.
• The query string — optional ?key=value&key=value pairs that pre-fill subject and body.
• URL encoding — every space becomes %20, every & inside a value becomes %26, every newline in the body becomes %0A. This is where most homebrew encoders get it wrong.

Three real examples that scan cleanly into a phone:

mailto:hello@you.com
mailto:hello@you.com?subject=Saw%20your%20card
mailto:hello@you.com?subject=Beta%20test&body=Hi%2C%20I%20saw%20your%20launch%20post

The third one — name plus subject plus body — is where this format earns its keep. The recipient scans, their phone opens the mail app with everything pre-staged, and they get to actually introduce themselves rather than figure out what tone you'd accept.

When this beats a vCard#

A vCard QR code drops your name, phone, address, and company into the recipient's contacts list. Useful when:

• You want them to have your full contact details on file for later
• You're at a long-running networking event where they collect cards from many people
• The relationship is "we should be in each other's address books"

A mailto QR opens a draft email with you. Useful when:

• You want a reply, not a saved contact
• You're handing out one-off leads (sticker on a product, leaflet, packaging insert)
• The fastest "yes" you're going to get is a one-line email
• You only need an address — there's no real "Dave Heere, +31 6, kingdom of the netherlands" to save

The decision usually comes down to "do I want to be added to their contacts list, or do I want a reply?" Most lead-capture moments — booth scanner, conference giveaway, lead-magnet PDF — fall on the "reply" side, where the mailto QR works harder.

Why the pre-filled subject and body actually matter#

Asking someone to email you cold is a friction problem. They have to think about who you are, what to say, what tone you'll accept, whether their question is dumb, what kind of response they're hoping for. Most people give up at "what do I write."

A pre-filled subject removes the first decision. A pre-filled body removes the next two. By the time the email draft opens, the recipient just has to add their name, maybe one specific question, and tap send. Friction drops by a factor of three.

A pattern that works for conference cards:

mailto:hello@you.com?subject=Saw%20your%20card%20at%20%5BEvent%5D&body=Hi%20%E2%80%94%20I%27m%20%5Byour%20name%5D%2C%20I%20saw%20your%20card%20at%20%5BEvent%5D%20and%20wanted%20to%20%5Bask%2Frequest%2Fpitch%5D...

The [brackets] in the body act as instructions for the recipient — they fill them in and hit send. You get a draft that already says where they met you, who they are, and roughly what they want. You haven't asked any of those questions; the body did the asking for them.

The same trick works for product packaging. Someone scans the box, the email opens with subject=Question%20about%20%5Border%20number%5D&body=Hi%20support%2C — they type their order number, send, you have a support ticket already on the right inbox.

Common encoding pitfalls#

Mailto URLs break in interesting ways when you skip the URL encoding step. The phone parser is strict — it'll either show you the literal raw string or refuse to open the mail app at all.

The five characters that get most homebrew encoders in trouble:

• Space — must be %20 (not +, despite what some old web forms taught you). + works in form-encoded query strings but not in mailto URLs reliably; some parsers literally insert the + character into your subject.
• & — must be %26 inside a subject or body, otherwise the parser thinks you're starting a new query parameter. "Bread & butter" with a literal & becomes "Bread " (subject) plus a parameter butter= that nothing reads.
• Newline — must be %0A. Don't put literal line breaks in the URL.
• ? — must be %3F inside body or subject (it's a valid character, but the parser already used it as the divider between address and query string).
• # — must be %23. Otherwise the parser truncates everything after the # (it interprets the # as a fragment, which mailto URLs don't have).

Most QR generators handle this correctly. The Linked.Codes Email destination type does the encoding for you — you type the subject and body in plain English, the encoder produces the right URL. Hand-rolling the URL is where you can quietly land a broken QR on every printed sticker.

Mobile parser quirks#

iPhones handle mailto QRs cleanly through the Camera app. Scan, tap the prompt, the default Mail app opens with everything pre-filled. iOS lets the user pick which mail client handles mailto: URLs — Gmail, Outlook, Spark, Hey, ProtonMail are all options. Whatever they've configured as the default, that's what opens.

Android is more chaotic. The behaviour depends on:

• Whether they have a default mail app set. If yes, that app opens. If no, Android prompts them to choose — adding an extra tap.
• Whether they're using Google Lens vs the camera. Lens treats mailto URLs as known intents; the bare camera treats them as web URLs and may need a confirmation tap.
• Whether the Android version is recent enough. Older builds (pre-Android 9) sometimes can't parse body= pre-fills with newlines or non-ASCII characters.

The practical effect: on iOS, the mailto QR is essentially friction-free. On Android, expect one extra tap to choose a mail app. Test on both before printing.

Build one#

The widget below builds the mailto: URL from your inputs and shows you the URL-encoded payload to drop into a QR generator. URL encoding is handled with encodeURIComponent so all the special-character traps above are taken care of automatically.

If the destination is something you might want to change later — a campaign address, a seasonal contact, an inbox you might rotate — set this up as a dynamic short link on a Linked.Codes Email-type destination. The QR encodes the short URL; the redirect serves the right mailto: every time.

Where this format falls apart#

Mailto QRs are simple, which means the failure modes are also simple. Three to know about:

Long bodies. A QR comfortably encodes about 1,800 characters at error-correction level Q. A long pre-filled body — say, three paragraphs of context — adds up fast once URL encoding is applied (a single space becomes three characters). Past about 1,500 characters of payload, the QR's pixel grid gets dense enough that small print sizes stop scanning. Keep the body under 250 characters; if you need more, link to a page that has the long version.

If your pre-filled body is longer than your business card, you didn't want a mailto QR. You wanted a landing page.

Email addresses with special characters. RFC 5322 allows a surprising range of characters in the local part of an email address — periods, plus signs, hyphens, even quoted strings with spaces. The mailto URI spec restricts this; some parsers tolerate the variations and some don't. If your address is dave+conf@example.com, test the QR on both iOS and Android before printing. Plain alphanumeric addresses are safe.

Recipients without a mail app set up. A small but meaningful share of phones have no default mail client configured — the user uninstalled the stock app, never opened Gmail, only uses webmail in a browser. Their mailto QR scans into a "no app available" prompt. There's no clean fix; this is the recipient's setup, not yours. The fallback is a tiny webpage that says "or email me at hello@you.com" so they can copy-paste.

Related reading#

If you're working through which QR format fits your use case:

• vCard QR codes — the modern business card — when "save my contact" beats "reply to me"
• Calendar event QR codes — get an event into a phone fast — same pattern, different intent
• WiFi QR codes — share without sharing — sister structured-payload format
• URL vs short-link QR codes — when to encode the destination directly vs going through a short link
• Static vs dynamic QR codes — editing trade-offs after print