# Email QR code body loses its line breaks

> RFC 6068 requires line breaks in a mailto: body to be percent-encoded as %0D%0A. A raw newline breaks the URI, a lone %0A is ignored by some clients, and a + is not a space. Percent-encode everything, keep the body short, and decode the finished code to check it.

Source: https://useqr.app/docs/troubleshooting/email-qr-code-body-line-breaks · Last reviewed 2026-08-21 · UseQR is free forever, MIT licensed, no signup.

---

## 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](/email-qr-code) 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](/docs/reference/qr-code-capacity-table)). At business-card size that is
already [too dense to scan reliably](/docs/troubleshooting/qr-code-too-dense-to-scan).

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](/feedback-qr-code) validates its inputs, which a mailto body
never can.

## Verify the round trip

Decode the finished code with our [scanner](/scan) 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](/validate) 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.

## Try it

- https://useqr.app/email
- https://useqr.app/scan
- https://useqr.app/validate