Version information: how big symbols declare their size

Only from version 7

QR versions 1–6 carry no version field at all. Their size is small enough that a decoder can establish it by measuring: count the modules along the timing patterns, or divide the distance between finder centres by the measured module pitch. At 21–41 modules per side, the difference between adjacent versions (4 modules) is a large, safe fraction of the whole.

From version 7 (45 × 45) upward the arithmetic gets fragile: a small pitch misestimate across a large symbol can land on the wrong version, and a wrong version means a wrong sampling grid, wrong alignment pattern positions and wrong block structure. So versions 7–40 state their version explicitly, with heavy protection.

The 18-bit word

Bits	Content
6	Version number, 7–40 in binary (000111 to 101000)
12	BCH(18,6) error-correction bits

Unlike format information, no XOR mask is applied: the version bits are never all zero, since the field only exists from version 7.

Worked example: version 7 is 000111; the BCH remainder extends it to 000111110010010100. Version 8 encodes to 001000010110111100. The BCH(18,6) code has minimum distance 8, so a decoder can correct up to 3 bit errors in each copy, and, as with format bits, there are only 34 valid words, so exhaustive nearest-match against the full list is a practical last resort.

Where it lives

Written twice, in mirror-image positions:

• a 6 × 3 block immediately above the bottom-left finder pattern,
• a 3 × 6 block immediately left of the top-right finder pattern.

Both sit inside the corner regions a scanner has already located before it needs the version, which is the point: the decoder reads finders, then version, then builds the grid, then reads format information, then data.

Why redundancy here matters

The version field is the decoder's declaration of geometry. Get it wrong by one and every downstream structure shifts: the symbol claims a different module count, the alignment grid lands in the wrong places, and the codeword count changes. There is no graceful degradation. It either matches reality or nothing decodes. Hence the same defensive design as format bits: strong BCH, two copies, tiny valid-word space.

For designers the practical consequence is one more pair of keep-clear zones. Styling that crowds the top-right or bottom-left finder on a version 7+ code: large payloads, bulk-generated vCards, long URLs, risks bits that error correction in the data region cannot help with. If your payloads are long enough to push past version 6, check where they land with the version and module table and verify the styled output.

FAQ

What is version information in a QR code?

An 18-bit field present only in versions 7–40: six bits stating the version plus twelve BCH(18,6) check bits. It is written twice, above the bottom-left finder and left of the top-right finder, so the decoder knows the symbol size without measuring.

Why do small QR codes not have version information?

Versions 1–6 are small enough that decoders determine the size reliably by counting timing-pattern modules. The explicit field only becomes necessary at version 7, where measurement error across a large symbol could land on the wrong size.

How many errors can the version field survive?

Up to 3 bit errors per copy, thanks to the BCH(18,6) code's minimum distance of 8, and there are two copies. Decoders can also compare a damaged read against all 34 valid version words and take the closest match.

Can I tell a QR code's version by looking at it?

Yes, count the modules along one side and apply size = 4 × version + 17. A 25-module side is version 2; a 45-module side is version 7, the first version that also carries the explicit field.