QR Code Versions 1-40: Module Counts and What Changes
Count the modules along one edge of any QR code, subtract 17, divide by four. That number is the version, somewhere from 1 to 40, and it explains more about the symbol than anything else you can measure from the outside.
Version 1 is 21x21 modules. Each step up adds four modules per side: 25x25, 29x29, 33x33, and onward to version 40 at 177x177. The sequence is fixed, with no gaps and no optional sizes in between. Version 1 covers 441 module positions; version 40 covers 31,329.
What grows with the version
Three things scale up as the version rises.
Capacity is the obvious one. More modules means more codewords, and more codewords means more room for both data and error correction. The tables by version, mode and correction level live in how much data a QR code can hold, so they are not repeated here.
Alignment patterns are the second. Version 1 has none. Versions 2 through 6 have exactly one, in the lower right. From version 7 the count jumps to six, then thirteen, then twenty-two, thirty-three, and forty-six at versions 35 to 40. The pattern behind those numbers is simple: alignment centers sit on a square grid, and the three grid positions that would collide with the finder patterns are dropped. Four grid points minus three gives one. Nine minus three gives six. Forty-nine minus three gives forty-six.
Block structure is the third and least visible. Beyond a certain size the codewords are divided into several error correction blocks rather than one long run, each with its own check data, then interleaved across the symbol. That keeps the Reed-Solomon math bounded and spreads localized damage across blocks.
What stays the same at every version
The three finder patterns never change. Always three, always 7x7 modules, always in the top-left, top-right and bottom-left corners, always with a one-module light separator on their inner edges. A version 40 symbol has the same corner squares as a version 1 symbol, which is why the same location routine works across the whole range.
The two timing patterns never move either. One row and one column of alternating dark and light modules run between the finders, at a fixed offset from the top-left origin. They get longer as the symbol grows, but their position and their alternating rhythm are constant.
Format information is present in every version, version 1 included: fifteen bits recording the error correction level and the mask pattern, stored twice in two separate places so damage to one copy is survivable.
The quiet zone stays at four modules of clear margin on all four sides regardless of version. So does the single always-dark module that sits beside the lower-left format strip. Together these are the reason a QR code of any size still looks like the same object.
Version information is not the version
Confusingly, the version information block is absent from most versions. It only appears from version 7 upward: two 6x3 blocks of eighteen bits, one near the top-right finder and one near the bottom-left, each carrying the version number plus error-detecting bits.
Below version 7 the decoder does not need it. The module count alone gives the version, and small symbols are easy enough to measure accurately. In larger symbols the module count is harder to establish from a warped or low-resolution image, so the version is written down explicitly.
Nobody chooses the version by hand
The encoder picks it. You supply content, the encoder works out the encoding mode, counts how many bits the content needs, adds the overhead for mode indicator and character count, then takes the error correction level you asked for and finds the smallest version where the data fits alongside the required check codewords.
Three inputs, one output. Change any of the three and the version can move. That includes changing the error correction level while the content stays identical, which is the interaction most people miss.
Version creep, and how to spot it
Here is what it looks like with real numbers, in byte mode at level M.
A 26-character URL fits inside version 2, whose byte capacity at level M is 26. Add a standard set of campaign parameters and the same link runs to around 90 characters. Version 5 tops out at 84 bytes at that level, so the encoder moves to version 6, which holds 106. The grid goes from 25x25 to 41x41. At an unchanged printed width of 30mm, module size drops by roughly a third, and the code that read comfortably from arm's length now wants to be held closer or printed larger.
Two habits keep this under control. Put a short redirect URL behind the code and carry the campaign parameters on the destination side, which is what a dynamic QR code is for. And regenerate the proof after any content change instead of assuming the artwork you already approved still applies. If the symbol densifies, either the physical size goes up or the print resolution has to follow it up.
Reading the version off a finished code
Zoom in until individual modules are countable and count along the top edge, from the outer edge of the top-left finder to the outer edge of the top-right one. Exclude the quiet zone, since that margin is not part of the grid. Then apply the arithmetic: subtract 17 and divide by four. A 25-module edge gives version 2. A 57-module edge gives version 10.
Two sanity checks come free. The result should be a whole number between 1 and 40; anything else means you miscounted. And if you can see the two small 6x3 blocks of version information tucked beside the top-right and bottom-left finders, the version is at least 7.
The number that matters downstream is not the version itself but what it does to module size. Divide your printed width by the module count per side and compare the result against the smallest module your production process holds cleanly. That single division, covered in more detail in the size guide, catches most of the failures that get blamed on scanners. The full decode sequence explains why small modules break it.
