How the mailto payload works
The code contains a mailto URI: the address, then optional subject and body as query parameters. Spaces, ampersands, colons and line breaks are percent-encoded so they stay data instead of breaking the URI apart.
A booking request looks like this on the wire:
The mailto standard also defines cc and bcc parameters, but scanner and mail-app support for them is patchy; this generator sticks to the three fields — recipient, subject, body — that phones handle consistently.
mailto:[email protected]?subject=Table%20for%20two&body=Friday%20at%2019%3A00Writing a subject and body that survive encoding
Keep both short. Every space and punctuation mark becomes a three-character escape sequence in the payload, so a chatty body inflates the code's density fast. A one-line prompt the sender completes ('Order number: ') works better than a pre-written essay.
Line breaks in the body are supported through encoding, but how faithfully they render differs between mail apps. If exact formatting matters, test in the app your audience actually uses rather than trusting the spec.
A practical trick: put a recognisable word in the subject — 'Poster enquiry', 'QR feedback'. Static codes have no analytics, but a distinctive subject line lets your inbox tell you which scans turned into emails.
What iPhone and Android do with it
Both open a compose screen in the default or chosen mail app with the fields pre-filled. The person scanning can edit everything, and must deliberately press send — a mailto code cannot dispatch mail by itself.
The failure case worth planning for: a phone with no mail app configured does nothing useful with mailto. On printed material, keep the address visible as text next to the code so those people can still reach you.
Mistakes that break email codes
Encoding a webmail URL instead of an address. mail.google.com is where you read mail; the payload needs the address itself. The generator builds the mailto wrapper — you only supply the parts.
Typos in the address are undetectable by any generator: there is no way to check that a mailbox exists without sending to it. Scan your exported code once and send yourself the draft — that single test email is the only real validation.
Assuming delivery equals notification. Nothing tells you a scan happened; you learn about it when the email arrives, and only then.
Where an email code fits
It suits low-volume, considered contact: feedback posters, support labels on equipment, press or venue enquiries, RSVP by email. The pre-filled subject does the routing that a web form would otherwise do — 'Warranty claim' and 'Bulk order' can even go to the same address as two different codes and sort themselves in your inbox.
Know what mailto cannot do before you commit the print: it cannot attach files, cannot force a format, and cannot stop the sender from editing every field. If people must submit a photo or a document, print a link to an upload form with a URL code instead.
One more consideration for public placements: an email address in a QR code is exactly as harvestable as an address printed in words — decoding is trivial. Use a role address (support@, bookings@) you can filter or retire, not a personal one.
If you want the phone to make a call instead, use a phone code; for a saveable contact card with several channels at once, a vCard carries name, number, email and company together.
Frequently asked questions
Can the QR code include a subject and message body?
Yes. Both travel as percent-encoded query values in the mailto URI and appear as editable draft fields in mail apps that support them — which is nearly all of them.
Does scanning send the email?
No. It only opens a draft. The person scanning reviews, edits, and sends it themselves — or discards it.
Will it work with Gmail and Outlook?
The code asks the operating system for its email handler, so whichever app is set as default — Gmail, Outlook, Apple Mail, anything else — answers the request.
Can I add CC recipients?
The mailto standard defines cc and bcc, but phone support is inconsistent, so this form keeps to recipient, subject and body. If you need copies, handle the routing on your side of the inbox.
Build the mailto payload as a URI, not as a sentence
For [email protected], subject `Table for two`, and body `Friday at 19:00`, the generated payload is `mailto:[email protected]?subject=Table%20for%20two&body=Friday%20at%2019%3A00`. The spaces and colon are percent-encoded because query delimiters have meanings of their own. RFC 6068 defines the mailto URI syntax and says that reserved characters such as `?`, `=` and `&` must be escaped when they are data: https://www.rfc-editor.org/rfc/rfc6068 . An ampersand inside the requested subject must become `%26`; otherwise it begins a second query field. Do not put a customer name, account number or confidential request in a public printed body: anyone can photograph and decode the payload before a mail app is opened.
Test the draft on the audience's mail path
Print one proof, scan it on an iPhone and an Android phone that have different configured mail handlers, then check recipient, subject and line breaks in the compose screen. The success condition is an editable draft, never an automatically sent message. A long prefilled body makes the QR denser and often obscures the actual intent, so use a short prompt such as `Please include your preferred date and time.` and put detailed instructions on a labelled web page if necessary. If a device merely displays the URI, provide the address visibly beside the code so the reader can still send mail. Save the exact URI and test date with the artwork. The generator can encode the standard syntax locally; it cannot prove that a mailbox is monitored, that an installed client permits all header fields, or that a user will consent to send the draft.
Keep a non-QR contact path on the sign
Print `[email protected]` beside the code and say what the email is for. A reader whose mail app is unavailable can copy the address, while a reader who scans can see the same recipient before sending. The visible address also lets staff spot a stale mailbox during proofing. Replace the code and the printed address together when the inbox changes; updating only one creates two conflicting support routes.
Avoid unsupported mail fields
Restrict a public code to recipient, subject and a short body. Different clients can handle optional headers differently, while RFC 6068 warns that fewer interpreted fields reduce unsafe behaviour. A simple draft is also easier for a scanner to inspect before it is handed to a mail application.