Structured append — splitting data across multiple QR codes

What the standard provides

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.

The honest part: almost nothing reads it

Structured append is real, standardised since the first edition of ISO/IEC 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 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 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. 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.

Whatever the route, verify every symbol decodes 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.