# Structured append — splitting data across multiple QR codes

> Structured append is the QR feature that splits one message across up to 16 symbols, each carrying a header with its position, the total count and a shared parity byte. It is in the standard and works with industrial readers, but phone camera support is effectively non-existent, so avoid it for public-facing codes.

Source: https://useqr.app/docs/spec/structured-append-multi-part-qr · Last reviewed 2026-08-21 · UseQR is free forever, MIT licensed, no signup.

---

## What the standard provides

[Structured append](/glossary/structured-append) lets an encoder split one logical message
across **2 to 16 QR symbols**. A reader scans them in any order, checks they belong
together, and reassembles the original data. Each symbol in the set starts with a
structured-append header before its normal data segments:

| Field | Size | Content |
|---|---|---|
| Mode indicator | 4 bits | `0011` |
| Symbol position | 4 bits | This symbol's index in the sequence |
| Total count | 4 bits | How many symbols the set contains (up to 16) |
| Parity | 8 bits | XOR of every data byte of the *entire* message |

The parity byte is the linking key: it is identical across the set, computed over the
whole original message, so a reader can tell that a stray symbol from a different set does
not belong — two sets colliding on all of position, count *and* parity is unlikely by
accident. Total overhead is 20 bits per symbol.

Sixteen symbols at maximum capacity is a theoretical ceiling of about
**47 KB** (16 × 2,953 bytes at version 40-L) — far past any single symbol's
[capacity limit](/docs/spec/how-much-data-fits-in-a-qr-code).

## The honest part: almost nothing reads it

Structured append is real, standardised since the first edition of
[ISO/IEC 18004](/glossary/iso-18004), and supported by industrial 2D imagers from the
major scanner vendors, where a firmware setting buffers symbols until the set completes.

Phone support is a different story. **iOS Camera, Android's native scanning and Google
Lens do not reassemble structured append sets** — at best they read each symbol as an
independent code and act on its fragment, at worst the leading header makes the fragment
look like garbage. Mainstream libraries are little better: [ZXing](/glossary/zxing)
exposes the header metadata but leaves reassembly to the application, and almost no
application implements it. For any audience scanning with their own devices, structured
append is a dead letter.

## What to do instead

The need is real — more data than one comfortable symbol holds — but the workable answers
are elsewhere:

- **Put the content behind a URL.** A short link to a hosted page, PDF or
  [file](/pdf-qr-code) reduces the symbol to a few dozen bytes and scans instantly. This
  is the right answer for public codes in almost every case.
- **Use one bigger symbol — up to a point.** A single version 20–25 code holds ~500–1,000
  bytes and still scans if [printed large enough](/docs/print/qr-code-size-for-print).
  Past that, density starts costing reliability.
- **Split at the application layer.** Ship several *independent* codes labelled "1 of 3",
  each a complete, self-describing payload, and let software or the user combine them.
  Animated multi-frame schemes used by air-gapped wallets and data-transfer apps work this
  way — custom protocol, ordinary symbols.
- **Industrial pipelines only**: if you control the readers end-to-end, structured append
  works as designed — enable it in the scanner configuration and
  [test the exact hardware](/docs/scanning/hardware-barcode-scanners-and-qr).

Whatever the route, [verify every symbol decodes](/validate) as the reader will actually
consume it — fragments included.

## FAQ

### Can one QR code's data be split across multiple codes?
The standard's structured append feature spans one message across up to 16 symbols, linked by position, count and a shared parity byte. It works on configurable industrial scanners but not on phone cameras, which read each symbol independently.

### Why does my phone not combine multi-part QR codes?
Because iOS and Android camera apps never implemented structured append reassembly. They treat each symbol as a standalone code, so the set decodes as disconnected fragments. There is no setting to change this.

### What is the parity byte in structured append?
The XOR of every data byte of the complete original message, stored identically in each symbol of the set. Readers use it to confirm that scanned symbols belong to the same message before reassembling them.

### How should I share data too big for one QR code?
Host the content and encode a short URL — that is the reliable public answer. Alternatives: one larger symbol printed at adequate size, or application-level splitting into independent labelled codes that your own software reassembles.

## Try it

- https://useqr.app/text
- https://useqr.app/url
- https://useqr.app/validate