Email QR Code Generator
Open a pre-written email with one scan.
Enter your address below, and optionally a subject and body. Scanning opens the person's mail app with the draft already prepared — they add what they want to say and hit send.
Customize
Scanning opens the phone's default maps app centered on this point.
The end time must be after the start time.
Leave the date blank to preview with a sample event. Defaults to a 1-hour event if no end time is set.
We tested this against a real scanner: codes start failing between 16% and 20% of the area, so 15% is the safe ceiling. How we measured it.
Pick a preset to fill in the dot and background colors below, or skip this and choose your own.
Light backgroundsLight dots read fine on dark backgrounds on screen, but most scanners are tuned for dark-on-light -- test before printing at volume. Scan reliability tips.
This content is too long to encode in a QR code. Shorten it before downloading or saving. Why there's a limit.
These colors are close in tone and may be hard for some scanners to read. Consider more contrast. Choosing colors that scan.
Preview
Dynamic QR codes redirect to a web address, so they're available for the URL and WhatsApp types. Other types encode their content directly and can't be repointed later.
Generated in your browser — nothing is uploaded or saved.
The subject line is free attribution. Almost nobody uses it.
This is the reason to choose this type over printing an address, and it costs nothing. Put the location in the subject and your inbox becomes an attribution system with no analytics, no cookies and no consent banner:
Enquiry — trade show boothon the booth backdrop.Enquiry — brochureinside the brochure.Repair request — Unit 4Bon the appliance itself.Quote — yard sign, Elm Ston the sign.
Same mailbox, different codes, and you can tell at a glance which piece of print is actually producing enquiries. Filters and labels then route them automatically. Doing the equivalent with a web form and a tracking parameter takes an afternoon; this takes a subject line.
A pre-filled body does the same job for structured requests — a short template listing the three things you always have to ask for anyway (model number, address, preferred time). People fill in the blanks because the blanks are already there.
Everything you prefill is visible and editable
Worth being unambiguous: the subject and body are a convenience for the sender, not a hidden field. They can read all of it and change all of it before sending. Do not put anything in there you would not want altered or seen — no internal reference codes you rely on being accurate, no assumptions about who is really sending.
Treat anything that comes back as user-supplied, because it is.
Always print the address as well
The draft opens in whatever the phone has configured as its default mail app. On a device where the owner uses webmail in a browser and has never set one up, the scan does nothing useful at all — no error, no explanation, just a dead end.
That population is small but real, and it is invisible to you because they cannot contact you to complain. Printing the address in readable text next to the code costs a line and removes the failure mode entirely. It also lets someone note it down to write from a desktop later, which for a considered B2B enquiry is often what they would rather do anyway.
Keep the template short for a second reason
The subject and body are both encoded into the pattern, so a long template produces a noticeably denser code. A three-line template is fine. A paragraph of instructions is how you end up with something that will not scan from a poster at arm's length.
If you need to collect a lot of structured information, a link to a form is the better tool — at the cost of a page load and a form nobody enjoys filling in. Email wins where you want an actual conversation and a reply-able thread; forms win where you want clean data.
Frequently asked questions
Does scanning send the email automatically?
No, and it cannot. It opens a draft that the person has to send themselves. No platform allows a scanned code to send mail on someone's behalf, which is the behaviour you want regardless.
Can I add a CC or multiple recipients?
Not from here — one address. If several people need to receive it, use a group alias that forwards to all of them. That is more robust anyway, since it survives someone leaving without reprinting anything.
Nothing happened when I scanned it.
Almost always no default mail app configured on that device. It is common on phones belonging to people who only ever use webmail. This is exactly why a printed address alongside the code earns its space.
Will this get my address harvested by spammers?
Any address on public print can be collected, and a QR code is trivially decodable by software. It is no worse than printing the address in text, but it is no better either — the code is not obfuscation. Use normal filtering, and prefer a role address like hello@ over a personal one on anything widely distributed.
Should I use this or a contact form?
Email when you want a real conversation, when the enquiry is not predictable enough to structure, and when you want the person to have a copy of what they sent. A form when you need consistent fields you can process. For most printed material aimed at the public, email converts better because it asks for less.