What the scanner actually receives
An email QR code encodes a mailto: URI — the same standard defined in RFC 6068 that powers every "email us" link on the web. Scanning it opens the phone's default mail app with the fields already filled in. Nothing is sent automatically; the user still has to press send.
mailto:[email protected]?subject=Order%20%23A4192&body=Hi%2C%20I%20need%20help%20with%3A
Three parts: the recipient address, an optional subject, and an optional body. Everything after the ? is a query string, which brings a rule that catches most people out.
Percent-encoding is not optional
Query strings cannot contain raw spaces, and several other characters have structural meaning that must be escaped. If you hand-build a mailto: URI and skip this, the subject line truncates at the first space or the body silently loses everything after an ampersand.
| Character | Must be written as | Why |
|---|---|---|
| space | %20 |
Terminates the URI in many parsers |
& |
%26 |
Separates query parameters |
? |
%3F |
Starts the query string |
# |
%23 |
Starts a fragment |
| newline | %0A |
Cannot appear literally |
+ |
%2B |
Otherwise decoded as a space |
That last one is a genuine trap. In application/x-www-form-urlencoded a + means a space, and some mail clients apply that rule to mailto: bodies. A phone number written as +44 20 7946 0018 in a pre-filled body can arrive as 44 20 7946 0018 with the plus eaten. Encode it as %2B.
The generator above handles all of this. It is worth knowing about anyway, because it explains why a mailto: link copied out of a document so often behaves strangely.
Multi-line bodies
Line breaks in the body use %0A (line feed). Some older Windows clients prefer %0D%0A (carriage return plus line feed), and both are accepted by every mail client in current use. A pre-filled support template looks like this once encoded:
mailto:[email protected]?subject=Support%20request&body=Order%20number%3A%0A%0ADescription%20of%20problem%3A%0A%0A
Which the user sees as:
Order number:
Description of problem:
This is the single highest-value use of an email QR code. A blank email gets you "it's broken." A pre-structured one gets you the order number, the device, and the actual symptom, which cuts a support round-trip out of every ticket.
Keeping the code scannable
Body text is the fastest way to bloat a QR code. Percent-encoding makes it worse: every space costs three characters instead of one, so a 200-character body becomes roughly 250 characters of encoded payload.
| Payload | Encoded length | Version at level M |
|---|---|---|
| Address only | 30 | 2–3 |
| Address + short subject | 65 | 4 |
| Address + subject + 3-line body template | 200 | 9 |
| Address + subject + paragraph body | 400 | 14+ |
Keep the body to field labels rather than prose. Order number: earns its bytes; Thank you for contacting us, please describe your issue below does not — the user is about to read that in your reply anyway.
Where email codes work well
Support and warranty cards in product packaging, pre-filled with the model number and a template. The customer does not have to find the model number on the base of the unit.
Trade show and conference stands — scan to request a quote, with the event name already in the subject so you know where the lead came from. This is meaningfully better than a business card because attribution is automatic.
Property and equipment signage — "report a fault" on a lift, a vending machine, a bike rack, with the asset ID pre-filled in the subject. Maintenance teams get an identifiable ticket instead of "the machine on the second floor."
Invoices and statements — a billing query code with the invoice number in the subject.
Printed forms and applications where you want submissions to arrive in a consistent, searchable format.
The address exposure problem
A mailto: code publishes the address in machine-readable form. Anyone scanning it sees the address in plain text, and if the code appears in a PDF, an image on a website, or any digital artefact, it is trivially harvestable at scale.
That is fine for support@ or sales@ — role addresses that already expect volume and sit behind filtering. It is a bad idea for a named individual's address on public-facing material.
Practical mitigations:
- Use a role address (
support@,bookings@,careers@) rather than a personal one, and route it internally - Use a per-campaign alias (
stand-2026@) that you can retire if it starts attracting spam, without disturbing your main inbox - On anything genuinely public and long-lived, consider a web form behind a URL code instead — it gives you spam protection, required fields, and routing that a
mailto:cannot
Behaviour across devices
iOS opens Apple Mail by default, and will offer alternatives if other mail apps are installed. If the user has no mail account configured, iOS shows a prompt to set one up rather than failing silently.
Android shows the app chooser when multiple mail apps are installed, or opens Gmail directly when it is the only one. Gmail respects subject and body parameters reliably.
Desktop scanners and webcam-based readers hand the URI to the operating system, which may open a desktop client the user has not configured. This is a common source of "your QR code doesn't work" reports that turn out to be an unconfigured Outlook.
Web-only mail users — someone who uses Gmail exclusively in a browser on a laptop but has no mail app installed — will get a dead end. On desktop-facing material, print the address as text alongside the code.
Testing checklist
- Scan with an iPhone and confirm the subject and body arrive intact, including any punctuation.
- Scan with an Android device that has more than one mail app installed.
- Check that a
+in the body survived, if you included one. - Confirm line breaks render as line breaks and not as literal
%0A. - Send the resulting email to yourself and check how it looks in your ticketing system, not just in the client.
Frequently asked questions
Does scanning send the email automatically?
No, and it cannot. The code opens a pre-filled draft in the user's mail app; sending always requires a deliberate tap. There is no mechanism in the mailto specification for automatic sending, which is what stops these codes from being abused.
Why did my subject line get cut off?
Almost certainly an unencoded space or ampersand. Everything after the `?` is a query string and must be percent-encoded — spaces become %20, ampersands %26. Generate the code with the tool above rather than editing the mailto string by hand.
Can I include multiple recipients or a CC?
The specification supports comma-separated addresses and cc / bcc parameters, but client support is inconsistent — some mail apps quietly drop the extra fields. For anything that must work reliably, use a single address and handle distribution with a mailing group on your side.
How long can the pre-filled body be?
There is no hard limit in the specification, but every character makes the code denser. Keep bodies to short field labels; past roughly 200 characters of body text the code needs a noticeably larger print area to stay reliable.
Will my email address get scraped?
If the code appears anywhere digital, assume yes — the address is stored in plain text and any scanner can read it. Use a role address or a disposable per-campaign alias rather than a personal inbox on public-facing material.
What happens if someone has no mail app set up?
iOS prompts them to configure an account. Android generally opens Gmail or the app chooser. On desktop the result depends entirely on the operating system's default handler and may go nowhere useful, which is why printing the address as readable text alongside the code is worth doing.
Is the email address sent to your servers?
No. The mailto URI is built and rendered in your browser. Nothing you enter into the form is transmitted to us.