QR Code Versions 1-40 Explained - Size and Capacity Guide

Version Means Module Count

A QR code's version defines its grid size. Version 1 is 21x21 modules, increasing by 4 per version up to Version 40 at 177x177 (31,329 modules). More modules means more data capacity but harder scanning - a fundamental tradeoff between capacity and readability.

Capacity by Version

At error correction level M: Version 1 holds 34 digits or 20 alphanumeric characters. A typical URL contains lowercase letters and falls into byte mode (14 bytes max at level M), so even a short URL like https://example.com starts at Version 2 in practice. Version 5 holds 202 digits or 122 alphanumeric (long URLs with UTM parameters). Version 10 holds 513 digits or 311 alphanumeric characters (basic vCard data). Version 40 holds 5,596 digits but is impractical for most uses due to tiny module size.

Auto vs Manual Version Selection

Most generators auto-select the version based on data length. Manual selection matters when print size is constrained: business cards need Version 5 or below (15-20mm limit), while large signage can accommodate higher versions with adequate module size.

Error Correction and Version Relationship

Higher error correction increases the version needed for the same data. Level L (7%) might need Version 3, while Level H (30%) needs Version 5 for identical content. Recommended: Level M for general use, Q for outdoor/dirty environments, H for logo-embedded designs.

Capacity and Scannability Are a Trade-off

Raising the version increases the data that fits, but if you print at the same physical size, each cell becomes proportionally smaller. Smaller cells are directly more vulnerable to worsening conditions: limited camera resolution, hand shake, dim light, ink bleed, and scanning at an angle. Even when dirt or scuffing covers the same area, the number of cells lost grows, so the point at which error correction can no longer restore the data arrives sooner.

For that reason, the version is closer to a result determined by the amount of data you embed than to a number you choose. You cannot lower the version alone to make a code easier to scan; if you want it lower, the only lever is the data itself. The order to think in is: keep the version as low as possible within the range where the necessary data fits.

In practice, decide the side length available on the medium first, then picture the distance the code will be scanned from, and derive the highest version that still keeps each cell large enough under those conditions. If the data you want to embed exceeds that ceiling, you have two choices: make the code physically larger, or cut the data. Because capacity and scannability are traded against each other, deciding in advance which one you are willing to give up keeps the design from stalling.

Know Where the Version Boundaries Fall

Capacity does not rise continuously with the version; it comes in steps. At error correction level M in byte mode, version 4 tops out at 62 bytes and version 5 at 84 bytes. The moment a 62-byte URL gains one character and becomes 63 bytes, the code switches from 33x33 to 37x37. Likewise version 7 tops out at 122 bytes and version 8 at 152 bytes, and crossing that boundary moves the code from 45x45 to 49x49.

Because of these steps, practitioners do not aim for the exact upper limit. Design at the top of a step and adding a single character to the URL later pushes the version up, changing how fine the cells look when printed at the same size. Staying within the limit of one step below means small swings in character count leave the coarseness of the pattern untouched.

A trap that is easy to miss is a URL containing non-ASCII characters such as Japanese. It looks like one character in the address bar, but what goes into the QR code is the percent-encoded form, where a single Japanese character occupies nine bytes. A four-character Japanese path adds 36 bytes, so a URL that fit in version 4 at around 60 bytes with ASCII alone can jump two or three versions at once.

If the destination may change after printing, fixing the length of the embedded string is the safer design. Routing through a redirect lets you swap the destination without touching the printed URL, so neither the version nor the pattern moves. Embedding the destination directly means the character count shifts with every swap, which media you cannot reprint have no way to absorb.

Recommended Versions by Use Case

URL only (up to 62 bytes): version 3-4. Business cards, flyers, posters and most other uses land here. At error correction level M, up to 42 bytes is version 3 and up to 62 bytes is version 4.

Wi-Fi credentials: version 5-7. This moves with the length of the SSID and the password. Version 5 holds 84 bytes and version 7 holds 122 bytes, so allow for version 7 if the password is long.

vCard (digital business card): version 10 and above. The basic fields alone come to around 200 bytes, and adding an address and job title pushes it toward version 17 (504 bytes). On a printing area as small as a business card, storing the shortened URL of a contact page is more practical.

Long text in a multi-byte script: in byte mode one character takes three bytes, so 150 characters come to 450 bytes and call for version 16. Codes above version 20 are not recommended outside specialized industrial uses, because the cells become so fine that printing and scanning conditions turn demanding.