Scanning opens a blank email addressed to you, with the subject and body already filled in if you want them. Useful for support cards and feedback forms.
Anything after the address is a query string, so a subject or a body has to be percent-encoded. A raw space or ampersand truncates the message silently, and the code still scans perfectly. Test the whole thing on a real phone rather than trusting how it looks in the editor.
Enter content to generate QR code
The code holds a mailto: address, optionally with a subject and body attached as parameters. The phone hands it to whichever mail app is set as the default, which opens a new draft with those fields populated. Nothing sends by itself and nothing is transmitted when the code is scanned. The draft simply sits there until the person decides to send it.
Address, subject and a one-line prompt, and the code holds:
mailto:support@example.com?subject=Warranty%20claim&body=Model%20and%20serial%3AA standard mailto with the subject and body as URL parameters, percent-encoded. Every space and colon costs three characters rather than one, which is why a long template makes a noticeably denser code.
The address alone saves someone typing; a fixed subject saves you sorting. "Warranty claim — model X" or "Feedback: Baker Street" arrives already labeled, which means a filter can route it and you can tell at a glance which sign or which product the message came from. Different codes with different subjects on different materials is the cheapest campaign tracking there is.
The body text is encoded character for character and URL-escaped, so spaces and punctuation each cost a few characters more than they look. A long template makes a dense pattern for text most people will delete anyway. A prompt of one line — "Please describe the problem:" — does the work without the bulk.
The draft opens in whatever the person has set as their default: Mail, Gmail, Outlook or something else. All of them honor the address and subject; a few older clients ignore the pre-filled body. Because of that, never put essential information only in the body. Anything the recipient must have should also be in the subject or printed beside the code.
Yes, and both are optional. A fixed subject is the more valuable of the two: it makes incoming mail filterable and tells you which code the sender scanned.
No. The draft opens in the phone’s mail app and the sender chooses whether to send it. Scanning the code sends nothing on its own.
Whichever is set as the default on that phone. Address and subject are honored everywhere; a small number of clients ignore a pre-filled body, so do not rely on the body alone for anything important.
A printed code is only readable by someone holding it, so it is not exposed the way an address on a web page is. Publishing the same code image online is a different matter, because a bot that scans images can read it exactly as a phone does.
An email code is instant and works offline, but you get whatever the sender types. A form gives you structured fields and validation. On print, an email code with a fixed subject is usually the better trade; for anything you need to process automatically, point a URL code at the form.
Not on this code. A mailto: instruction goes to the mail app rather than through a web page, so there is nothing to redirect. If the address may change, encode a dynamic code pointing at a contact page on your site and let that page carry the mailto link.