Email QR Code Generator

The code carries a standard mailto: link — the same format an email link on a webpage uses (defined in RFC 6068). Scanning it opens the phone's default mail app with a new draft: recipient from the link, plus subject and body if you provided them. Special characters in the subject and body are percent-encoded automatically, so "Q&A?" arrives as "Q&A?" and not as a broken link.

Because the draft opens in the visitor's own mail account, replies go through their address — you receive a normal email you can answer, which is often exactly the low-friction contact channel a poster or product needs.

The payload has three parts, and the builder assembles them in a fixed order. First the scheme, mailto:, which is what marks the string as an email link rather than a web address or plain text. Then the address, trimmed of surrounding whitespace and otherwise as you typed it, after a validation pass and one narrow encoding rule. Then — only when you filled in a subject or a message — a ? followed by the header fields, subject=… and body=…, joined by &. An address on its own produces a bare mailto: link with no question mark at all.

Two different encoding rules apply, because the two halves of the string answer to two different parts of the specification. The address is an addr-spec, and RFC 6068 §2 requires %, &, ; and = to be percent-encoded when they appear inside it. The builder does this in a single pass, so a literal % is encoded exactly once and never double-encoded, and every other character in the address — dots, plus signs, hyphens, digits — is left exactly as entered. The subject and message are header values, and they are encoded strictly to RFC 3986: every character outside the unreserved set (letters, digits, -, ., _ and ~) becomes a percent sequence. That is stricter than a browser's encodeURIComponent, which leaves the sub-delimiters ! ' ( ) * bare even though they are reserved characters; the builder encodes those too, so each header value contains only unreserved and percent-encoded characters. A space becomes %20, and a character outside ASCII — an em dash, an accented letter — becomes the percent-encoded bytes of its UTF-8 form.

These are conventions, not inventions of this site, and each is named with its source: RFC 6068 for the mailto: URI and the ZXing "Barcode Contents" wiki for how the URI is carried in a barcode, both verified against the live sources on 2026-07-20; the percent-encoding follows RFC 3986, which the builder's own comment cites. The builder is held to them by automated tests against independently constructed reference strings, hostile inputs included, and by the round-trip suite that renders each payload type to an image and decodes it back byte for byte. For how the same scheme-plus-encoding idea plays out across tel:, sms: and WhatsApp links, read the guide URI schemes: mailto, tel, sms and WhatsApp; the rest of the series is at /guides/.

Take the example apart from left to right. The scheme and the address come first and are untouched: feedback@example.com contains none of the four characters the addr-spec rule encodes. (Every address on this page is a fictional example.com one; none is a real mailbox.) Then ? opens the header fields. Here is each field as typed and as it appears in the payload:

Every payload below was produced at build time by calling the builder the form uses, on fictional inputs, and then handed to the same encoder for its symbol. Nothing here was typed by hand, and each example isolates one rule.

Set it beside the worked example and the cost of the headers is visible: the subject and message raised the version from 2 to 8, which is 24 more modules per side.

Read the subject against the payload. & became %26 and ? became %3F; both would otherwise be read as URI structure. % became %25, so the 50% survives instead of starting a bogus escape sequence. The parentheses, the apostrophe and the exclamation mark became %28, %29, %27 and %21. Those are the ones the strict rule adds; a browser's encodeURIComponent leaves them bare:

The builder applies the same strict rule to mailto: and sms: header values, so every character inside a header value is either unreserved or percent-encoded; the scheme, the @ and the ?, = and & separators around the values stay bare.

The + in the address is untouched, because the addr-spec pass encodes only %, &, ; and =; a plus-addressed mailbox goes into the code as written. In the message, the line break became %0A and each colon %3A, and the & between subject= and body= is, again, structure rather than text. The payload carries the line break as %0A; the engine's job ends there.

One rule remains that only the address can trigger. An address containing one of the four addr-spec characters is unusual, but the validator accepts it — it checks shape, not mailbox conventions — and the rule exists for it: news&events@example.com builds as mailto:news%26events@example.com, with the ampersand encoded inside the address in the single pass that guarantees it is encoded exactly once. The address-only payload shows the other side of the same rule: when none of the four characters is present, nothing in the address changes at all.

Side by side, every symbol on this page:

• Version and modules. The encoder chooses the version that holds the payload at the requested error-correction level, and the side length is 17 + 4 × version, so each step up adds four modules per side. More characters mean a higher version and, at any given print size, more and smaller modules. If the content will not fit even at the highest version the encoder supports, the generator refuses rather than guessing, with the message "This content is too long for a QR code. Shorten it or lower the error correction level."
• Error correction. Four levels, L, M, Q and H. The generator defaults to M and lets you choose any of the four when there is no logo; a logo overlay removes the choice, forcing H, and is capped at 16% of the symbol area — a cap set by decode testing in the round-trip suite, not derived from the theoretical ~30% EC-H recovery ceiling. The level reported is the one actually encoded, and it can be higher than the one requested: the reference encoder raises the level whenever doing so does not push the symbol into a larger version. The table below shows it happening.
• Quiet zone. The 4-module light border on every side is part of the symbol as ISO/IEC 18004 defines it. The renderer draws it into every SVG and PNG and offers no way to turn it off, so a downloaded image is 8 modules wider than the module count alone suggests.
• Print size. The PNG download comes in 3 preset widths, and for each the download panel reports the physical size at 300 DPI: inches are pixels divided by 300, and millimetres are inches multiplied by 25.4. The last two columns below divide that width among the modules — quiet zone included — for the shortest and longest payloads on this page.

The module widths are arithmetic on the readout, not a rule: they tell you how wide one square of this particular symbol is at each preset, and therefore what adding a longer message does to it. What they cannot tell you is whether a given print will scan. Error correction helps a damaged code read, but print size and contrast still matter, and the engine's position is the same for every type: treat a freshly generated code as untested until a real device has scanned it.

The same two payloads at every error-correction level

Requested level on the left; what the encoder produced for the bare address and for the full worked example on the right. Compare the two halves row by row.

Where the encoded level is higher than the requested one, that is the boost: the payload had capacity to spare in its version, and the encoder spent it on recovery rather than leaving it empty, at no cost in size. Where the two match, the next level up would not have fit without a larger symbol — or H, the top level, was already requested. Either way the level printed under a code is a fact about what was encoded, not a setting that was ignored.

• Feedback at the point of experience: a code in the hotel room, on the table, or on the invoice catches people while the impression is fresh — no form to build or host.
• Support with context baked in: pre-fill the subject with the product or location ("Issue — Ticket machine, Platform 2") and every message arrives pre-triaged.
• Print and packaging: a support address on the box that nobody has to type (and therefore nobody mistypes).

Prefill etiquette mirrors WhatsApp codes: seed context, keep it short, and leave the actual message to the sender. A body that is one prompt line ("What went well / what could be better:") gets more and better replies than an empty draft — or a pushy prewritten one.

The engine validates format, not truth, and on this page the line falls in a specific place. The address check is a shape test: no spaces, exactly one @, and a dot after it with characters on both sides. Anything else is refused with "This is not a valid email address.", and an empty field with "Enter the recipient email address." That is everything the builder can know about an address. It cannot know whether the mailbox exists, whether anyone reads it, or whether you typed the one you meant: mailto:feedbcak@example.com is a perfectly well-formed payload and, if the real address is feedback@example.com, a perfectly useless code. The subject and message are not checked at all, only encoded.

Shape checking has one consequence worth seeing once. The field takes an address, not a link: paste mailto:hello@example.com into it and the shape test passes — no spaces, one @, a dot after it — so the builder prepends the scheme a second time and encodes mailto:mailto:hello@example.com. The generator's "What the code contains" panel shows the payload exactly as it will be encoded, which is where a doubled scheme, a typo or a missing subject is caught before anything is printed.

Then there is everything that follows from the code being static. The address and headers live in the image; nothing routes through this site, so there is no redirect that can expire, break or be switched off, and no third party — including us — can hold the code hostage. The same fact means the code cannot be edited once printed, so a changed address is a new code, and scans cannot be counted. The encoding runs in your browser, and the examples on this page were computed at build time by the same engine, so if the encoding ever changed the copy would change with it or the build would fail. The sibling schemes share the boundary exactly — a tel: code cannot know a number is reachable any more than this one can know a mailbox is read — and the guide URI schemes: mailto, tel, sms and WhatsApp sets the four side by side.

• Cropping the quiet zone. The light border is not padding. It is the 4-module margin the standard requires, rendered into every download and impossible to disable here, because cropping it is the most common self-inflicted scan failure. Printing the code flush against artwork removes it just as surely as cropping the file does.
• Inverting the colours. Light modules on a dark background are rejected by many scanners, and the style panel warns separately for that case. It also evaluates your colour pair with the WCAG relative-luminance contrast formula and warns below 4.5:1. Both warnings are computed from the colours you chose, not guessed.
• "Scanning sends the email." It does not. The code opens a draft; the visitor writes and presses send, or closes it. The code cannot send anything on its own.
• "A wrong address would fail to encode." It encodes perfectly, as the typo above shows; the only check is shape. Scan a test code with a real device and confirm the draft is addressed where you meant before printing a run.
• "A longer message makes a better code." It makes a bigger payload, a higher version and smaller modules at the same print size — version 2 for the bare address against version 8 for the worked example.
• Typing the scheme yourself. The field takes the address; the builder adds mailto:. Typed in by hand, it is doubled, as shown above.

For instant-message channels, see the SMS code and the WhatsApp code; to hand over full contact details, use the vCard generator.