PIX QR codes — the EMV BR Code format explained

A PIX QR code is an EMVCo BR Code — a tag-length-value string ending in a CRC16 checksum — containing the payee's PIX key, name and city. Any Brazilian banking app reads it. The same string doubles as copia e cola, the text people paste when they cannot scan.

The payload

Not a URL — a length-prefixed field string defined by EMVCo and profiled by the Banco Central do Brasil:

00020126360014BR.GOV.BCB.PIX0114+55119123456785204000053039865802BR5913Cafe Central6009Sao Paulo62070503***6304A13F

Each field is ID (2 digits) + LENGTH (2 digits) + VALUE. Reading the string above:

ID	Length	Value	Meaning
`00`	02	`01`	Payload format indicator
`26`	36	…	Merchant account information (nested)
`00`	14	`BR.GOV.BCB.PIX`	GUI — identifies this as PIX
`01`	14	`+5511912345678`	The PIX key
`52`	04	`0000`	Merchant category code
`53`	03	`986`	Currency, ISO 4217 for BRL
`58`	02	`BR`	Country
`59`	13	`Cafe Central`	Merchant name, max 25 chars
`60`	09	`Sao Paulo`	Merchant city, max 15 chars
`62`	07	…	Additional data (contains the txid)
`63`	04	`A13F`	CRC16 checksum

The CRC16 is not optional

Field 63 is a CRC16/CCITT-FALSE over the entire string including the literal 6304 prefix of the checksum field itself, with the four checksum characters treated as absent during computation. Polynomial 0x1021, initial value 0xFFFF, no final XOR, output as four uppercase hex digits.

Get it wrong by one bit and every Brazilian banking app rejects the code outright. This is the single most common failure when people build BR Codes by hand or with a naive template — the fields look right and nothing works.

ASCII only

Merchant name and city are transliterated to ASCII and truncated: 25 characters for the name, 15 for the city. São Paulo becomes Sao Paulo. A non-ASCII byte that slips through breaks length counting, which breaks the CRC, which breaks everything.

Key types

The PIX key in field 26.01 can be any of five things:

Type	Example
CPF	`12345678901`
CNPJ	`12345678000199`
Email	`loja@example.com`
Phone	`+5511912345678`
Random (EVP)	`123e4567-e89b-12d3-a456-426614174000`

A random EVP key is the privacy-preserving choice for anything printed publicly: it reveals neither your tax id nor your phone number, and it can be rotated without changing your bank details.

Static, dynamic, and copia e cola

Static: fixed key, no amount, txid of ***. Print it and use it forever.
Dynamic: field 26.25 carries a URL to a payload hosted by your PSP, which returns amount and expiry. Requires a bank integration; the QR code alone is not enough.

The full BR Code string is copia e cola. Always print or display it as text alongside the code — a customer whose camera fails can paste it instead, and that single fallback removes most payment friction at a market stall or in a chat.

FAQ

What is copia e cola?

It is the same BR Code string as text. Anyone can paste it into their banking app's PIX screen instead of scanning. Always offer it next to the code as a fallback.

Why do banking apps reject my PIX QR code?

Almost always a wrong CRC16 checksum, or a non-ASCII character in the merchant name or city that broke the field-length counting. Both fail silently at generation and loudly at scan.

Should I use my CPF as the PIX key on a printed code?

Prefer a random EVP key. It works identically but does not expose your tax id or phone number to everyone who photographs the code, and you can rotate it without changing bank accounts.

Can a static PIX QR code include the amount?

It can, but for anything printed you should leave it out so the payer enters the value. A fixed printed amount becomes wrong the moment your prices change.

What is the difference between static and dynamic PIX codes?

Static codes contain the payment details directly and never expire. Dynamic codes contain a URL that your payment provider resolves to an amount and expiry, which requires a bank integration.