CRC16

Where QR codes use it

The QR symbol already protects itself with Reed–Solomon coding, but that only guarantees the decoded string matches what was encoded. Payment standards add a second integrity layer inside the payload itself: every EMVCo merchant-presented payload — PIX, PromptPay, QRIS and relatives — ends with field 63, a checksum over everything before it, computed as CRC-16/CCITT-FALSE: polynomial 0x1021, initial value 0xFFFF, no final XOR, rendered as four uppercase hex digits. UseQR's PIX builder implements exactly this, and the parameters here are taken from that working code.

...6304ABCD
   │ │  └ CRC over the payload up to and including "6304"
   │ └ length: 04
   └ field ID: 63

Why your edited PIX code stopped working

Change one character of a payload — fix a typo in the merchant name, bump an amount — and the stored CRC no longer matches. Banking apps are required to reject the code, and do, usually with an unhelpful "invalid QR" message. This is the single most common failure when people copy a Copia e Cola string into a generic text generator after tweaking it. The fix is never to edit by hand: rebuild the payload with a proper PIX generator so field 63 is recomputed, then decode and check it. Full field-by-field detail: PIX QR code format and its CRC16 checksum.

FAQ

Why is my edited PIX QR code invalid?

The payload ends in a CRC16 checksum of everything before it. Editing any character without recomputing field 63 makes the checksum wrong, and payment apps reject the code.

Does every QR code have a CRC?

No. The QR symbol itself uses Reed–Solomon, not CRC. A payload-level CRC16 is specific to certain formats — EMVCo payment codes like PIX carry one; a plain URL code has none.