Email QR Code: Create a Pre-Filled Mailto QR

The mailto syntax was checked against RFC 6068, and QRLynx Email QR behavior was checked against the current encoder and type contract in July 2026.

An email QR code stores a mailto: link that asks the scanner's device to open an email draft. QRLynx can pre-fill the recipient, subject, and message body. The person still reviews the draft and chooses whether to send it.

The Email type is static-only in QRLynx, and creating it does not require a paid plan. Its full mailto: payload is stored in the QR pattern, so the code does not depend on a QRLynx redirect. It also means the address and template cannot be changed after printing, and QRLynx cannot count scans of that Email QR.

What happens after someone scans

The scanner reads the mailto: payload and passes it to a compatible handler on the device. That may be Apple Mail, Gmail, Outlook, another installed mail app, or a browser-configured webmail service. The exact choice depends on the person's device and settings.

RFC 6068 describes a mailto URI as a message template, not an instruction to transmit email automatically. The mail client should show the decoded recipient and message fields and ask the user to approve sending. If the device has no email handler configured, the scan may show the payload without opening a useful draft.

Write a useful pre-filled message

A good template reduces typing without speaking for the sender. Use a specific subject such as Warranty question: product model or Quote request from showroom sign. In the body, ask for the missing information instead of filling in an approval, declaration, or sensitive statement on the sender's behalf.

• Keep the recipient and purpose obvious.
• Use a short subject that helps the receiving team route the message.
• Leave placeholders only when the sender can understand and replace them.
• Avoid passwords, payment details, private account data, or confidential information.
• Use %20 for spaces and UTF-8 percent encoding for non-ASCII text when constructing a mailto URI manually.
• Test punctuation, emoji, non-Latin text, and line breaks in the actual mail clients that matter to the campaign.

RFC 6068 supports header fields such as subject, body, and recipient fields. QRLynx's current Email generator exposes recipient, subject, and body. If your workflow requires CC or BCC, a different carefully tested mailto builder may be needed, and client behavior can still vary.

Email QR or dynamic contact page?

Use a static Email QR when the inbox and message template are expected to remain stable. It opens the email draft directly and does not insert a QRLynx web page or redirect.

Use a dynamic URL QR to a contact page when the printed material may outlive the inbox, when you want to offer email plus phone or form options, or when scan analytics matter. The dynamic QR tracks the visit to the contact page. It still cannot prove that the visitor sent an email, so compare scan activity with the messages actually received rather than calling scans email conversions.

The free Starter plan includes 3 active dynamic QR codes, unlimited scans, and three months of analytics for dynamic-capable QR types. A dynamic URL QR is a different QR type from QRLynx's static Email QR.

Where Email QR codes work well

• Business cards: open a draft to a stable role or professional inbox while keeping the printed address visible as a fallback.
• Product packaging and manuals: pre-fill a model or support category in the subject without putting private customer details in the QR.
• Receipts and table signs: ask for feedback through email when an open reply thread and attachments are useful.
• Property and showroom signs: identify the listing or location in the subject so the receiving team knows what prompted the message.
• Events: use a short topic-specific subject, then remove or redirect long-lived printed materials if the contact route changes.

For structured information such as an order number, consent choice, product category, or required attachment checklist, a contact form may be clearer because it can validate fields before submission.

Testing and privacy checklist

• Decode the final QR and inspect the complete mailto payload before distribution.
• Scan with at least one iPhone and one Android device when both are part of the audience.
• Confirm the message opens as a draft and is not transmitted automatically.
• Check the recipient, subject, message, punctuation, and line breaks.
• Print a physical sample at the intended size and material.
• Place a readable email address or alternative contact route near important public codes.
• Use an inbox and retention process suitable for the information people may send.
• Do not claim that creating the QR alone makes the resulting email workflow compliant with a privacy law.

A public Email QR reveals its encoded recipient and template to anyone who can scan or decode it. Treat the QR as public information. The email itself follows the sender's mail provider, the recipient's provider, and any intermediaries involved in delivery.

Create the simplest workflow that meets the need

For a stable inbox and a short message prompt, a static Email QR is direct and easy to test. For editable contact details, multiple contact choices, or scan analytics, use a dynamic URL QR to a contact page instead.

Start with the QRLynx QR code generator. If the printed material may need a new destination later, compare static and dynamic QR codes. Before production, check the exported image with the QR code readability checker.