Email QR code body loses its line breaks

The rule: CRLF, percent-encoded

An email QR code is a mailto: URI, and RFC 6068 is precise about line breaks in the body: they are carriage-return-line-feed pairs, percent-encoded as %0D%0A. A correct two-line body looks like this:

mailto:hello@example.com?subject=Site%20visit&body=First%20line%0D%0ASecond%20line

The failure ladder, from worst to subtlest:

• A raw newline in the URI is illegal: whitespace terminates or corrupts the URI, and depending on the generator the body is cut at the first line break or the whole link fails.
• A lone %0A (line feed without carriage return) works in many mail clients but is ignored by some, which is how a neatly formatted template arrives as a single wall of text for a subset of recipients. %0D%0A is the form the RFC specifies and the one every client honours.
• Nothing at all: the generator stripped the line breaks silently, and nobody notices until replies start quoting one giant paragraph.

The space and plus traps

Two more encoding mistakes cluster around mailto bodies:

• Spaces must be %20. The +-for-space convention belongs to HTML form encoding, not to mailto URIs. A generator that emits body=Hello+there produces "Hello+there" in strict clients.
• A literal + must be %2B. The mirror-image trap: leave a real plus sign bare (Call +44 20…) and any client applying form-decoding habits turns it into a space. Encoding it as %2B survives both interpretations.

UseQR's email generator percent-encodes subject, body and cc automatically (spaces become %20, plus signs become %2B), and validates every address (multiple recipients are accepted comma-separated). What you type in the body box is what arrives in the compose window.

The density cost of long bodies

Percent-encoding is expensive: every encoded character triples to three bytes, and every line break costs six (%0D%0A). The QR consequences add up fast: a 350-character body with a handful of breaks and spaces easily encodes to ~450 bytes of URI, which needs a version 16 code at EC M: an 81×81 module grid (see the capacity table). At business-card size that is already too dense to scan reliably.

The rule of thumb: keep prefilled bodies to a couple of short lines, enough to seed the message ("Booking enquiry, name: / date:") and no more. If you need a long structured message, a QR to a web form is the better tool: a ~30-byte URL gives you a version 2–3 code, and a feedback form validates its inputs, which a mailto body never can.

Verify the round trip

Decode the finished code with our scanner and read the raw URI: line breaks should appear as %0D%0A, spaces as %20, and nothing should be raw whitespace. Then do one live test: scan, let the compose window open, and check the formatting in the actual mail client your audience is likeliest to use. Our validator confirms the code itself decodes cleanly at the size you intend to print.

FAQ

How do I add a line break in a QR code email body?

Percent-encode it as %0D%0A inside the mailto body parameter. That is the CRLF form RFC 6068 specifies, and it renders as a new line in every mail client. A generator that handles this for you is more reliable than hand-building the URI.

Why does my email QR code produce one long paragraph?

The line breaks were either stripped at generation or encoded as a lone %0A, which some clients ignore. Decode the code and inspect the URI, if you do not see %0D%0A where the breaks belong, regenerate with proper encoding.

Why do plus signs in my email body become spaces?

Some clients apply form-style decoding, where + means space. A literal plus sign must be encoded %2B to survive everywhere, and spaces should be %20, never +. This commonly mangles phone numbers written with country codes.

How long can the body of an email QR code be?

Technically until the code hits its byte ceiling, but practically a couple of short lines. Percent-encoding inflates the byte count, around 350 body characters already forces a version 16 code that scans poorly at small print sizes.