QR code versions are the standardized size classes that define how many modules, or tiny black and white squares, a QR code contains, starting at Version 1 with a 21×21 grid and increasing stepwise to Version 40 with a 177×177 grid. In practice, when people ask what QR code versions 1–40 mean, they are really asking how QR code size affects data capacity, scan reliability, print requirements, and implementation choices. I have had to explain this repeatedly to product teams, printers, and app developers because many assume a “bigger QR code” simply means a physically larger label. It does not. Version refers to the internal grid, not the printed dimensions.
This distinction matters because QR Code standards and formats are built around predictable structure. A version determines where finder patterns, timing patterns, alignment patterns, format information, and version information are placed. It also determines how much data and error correction the symbol can carry. As the version number rises, the code can store more characters, but it also becomes denser. That density creates tradeoffs. A Version 2 code printed large on a poster can be easier to scan than a Version 20 code printed small on packaging, even if the latter technically stores more information.
Under the ISO/IEC 18004 standard, the QR Code model defines forty full-size versions. Each version increases by four modules in width and height. The formula is simple: size equals 21 plus 4 times version minus 1. That means Version 1 is 21×21, Version 2 is 25×25, Version 10 is 57×57, and Version 40 reaches 177×177. For anyone designing labels, payment flows, inventory systems, event tickets, or industrial marking workflows, understanding this progression is essential. It affects user experience, print production, decoding speed, and which QR code format is the right fit for a specific use case.
This hub article covers QR Code standards and formats through the lens of versions 1–40. It explains what a version is, how versions relate to capacity and error correction, why larger versions are not always better, and where Micro QR, Model 1, Model 2, and related format questions fit into the broader standards discussion. If you need one page that clarifies how QR code versions work before choosing generators, scanners, design rules, or development libraries, this is that reference.
What a QR code version actually defines
A QR code version defines the symbol’s matrix dimensions and structural layout. Every standard full QR code is square and made from modules arranged in rows and columns. The version number determines the count of those rows and columns. Version 1 contains 21 modules per side, and every next version adds four modules per side. The progression continues through Version 40 at 177 modules per side. That growth is not arbitrary. It creates room for more data codewords, more error correction codewords, and additional alignment patterns needed to keep scanning stable as density increases.
In implementation work, this is where misunderstandings start. Teams often think “size” means inches, millimeters, or pixels. Those physical dimensions matter only after version is selected. A Version 5 code can be printed at 15 millimeters wide or 150 millimeters wide; it remains Version 5 because its internal matrix is 37×37. The physical print size only changes module size, which affects whether a camera can resolve the pattern. That is why version choice and print sizing must be planned together, not separately.
Version also determines whether version information bits are required. Versions 1 through 6 do not carry explicit version information areas. Versions 7 through 40 do. Higher versions also incorporate more alignment patterns beyond the three finder patterns at the corners. Those alignment patterns help scanners compensate for distortion on curved surfaces, uneven printing, or perspective skew. On product packaging and corrugated materials, I have seen alignment patterns make the difference between instant reads and repeated scan failures.
Another key point is that version does not exist alone. Capacity depends on three variables working together: version, error correction level, and data mode. Numeric mode stores digits most efficiently, alphanumeric mode handles a limited character set, byte mode is common for URLs and UTF-8 text, and Kanji mode is optimized for specific character encoding. Two QR codes with the same version can have very different capacities depending on those settings.
How versions 1–40 scale in size and complexity
The forty versions form a predictable ladder from simple to highly dense symbols. The smallest practical examples appear in basic URL redirects, equipment tags, or short serial references, where Version 1 to Version 4 often suffices. Mid-range versions are common in payment payloads, vCard data, and offline authentication tokens. High versions appear when organizations try to embed long text, cryptographic signatures, or complex structured data directly in the symbol. In those cases, capacity rises, but so do scan constraints.
Here is the version growth pattern in a compact reference table.
| Version range | Matrix size | Typical use pattern | Scanning implication |
|---|---|---|---|
| 1–4 | 21×21 to 33×33 | Short URLs, IDs, basic links | Usually easiest to scan at small print sizes |
| 5–10 | 37×37 to 57×57 | App deep links, contact cards, short payment payloads | Good balance of capacity and robustness |
| 11–20 | 61×61 to 97×97 | Longer text, richer payloads, industrial data | Needs better print quality and adequate module size |
| 21–30 | 101×101 to 137×137 | Dense records, signatures, specialized workflows | More sensitive to blur, glare, and low-resolution cameras |
| 31–40 | 141×141 to 177×177 | Very high-density encoding, niche enterprise use | Demanding to print and harder for weak cameras |
In real deployments, most consumer-facing QR codes do not need versions above the low teens. A marketing landing page using a static URL should rarely exceed Version 4 or Version 5 if the redirect architecture is designed correctly. When I audit QR campaigns, oversized versions usually signal an avoidable problem: the creator encoded tracking parameters, campaign metadata, and long destination strings directly instead of using a short redirect. That creates a denser code with no user benefit.
On the other hand, industrial and regulated environments often have legitimate reasons to use higher versions. Manufacturing traceability may require embedding serials, lot references, production dates, and verification fields. Secure ticketing may include signed payloads. Some offline systems cannot rely on network lookups, so the symbol itself must contain the necessary data. In those cases, version selection becomes a design engineering decision, not a marketing convenience.
Capacity, error correction, and why bigger is not always better
QR code capacity is usually discussed as if a version has a single fixed storage limit. That is incomplete. Capacity changes with error correction level: L, M, Q, or H. Level L restores about 7 percent of codeword damage, M about 15 percent, Q about 25 percent, and H about 30 percent. Higher correction improves resilience but reduces available payload. This is one of the most important tradeoffs in QR Code standards and formats.
For example, a code used on indoor signage can often run safely at M or Q if print conditions are controlled. A code placed on machinery, exposed to abrasion, or printed on flexible packaging may justify H. However, if you raise error correction unnecessarily, the generator may bump the symbol to a higher version. That means more modules, tighter density, and sometimes worse practical scan performance despite theoretically stronger recovery.
Data mode has a similar effect. Numeric content packs efficiently, while byte mode is less compact. A 100-character numeric payload may fit in a much lower version than a 100-character mixed-case URL with symbols. This is why payment standards and industrial symbologies define strict field syntax wherever possible. Constrained formats improve efficiency.
Bigger versions are not always better because scanners read contrast transitions between modules, not abstract capacity. If modules become too small for the camera sensor, or if ink spread reduces white gaps, the symbol fails regardless of theoretical capacity. I have seen Version 15 codes fail on glossy labels where a shorter redirected URL in Version 3 scanned instantly under the same lighting. The smaller symbol was not physically larger; it was simply less dense.
The best practice is straightforward: encode the least amount of data necessary, select the lowest version that supports it comfortably, and choose the lowest error correction level that still matches the environment. This approach preserves generous module size and improves first-scan success.
Structural features that change across versions
All standard QR codes share core features, but higher versions add structure. The three finder patterns in the corners help a scanner detect orientation. Timing patterns run horizontally and vertically to establish module spacing. A quiet zone, typically four modules wide, must surround the symbol. Without that margin, even a perfectly generated code may not decode reliably because the scanner cannot separate the symbol from nearby text or graphics.
Alignment patterns are where version growth becomes more visible. Version 1 has none beyond the finder patterns. As versions increase, alignment patterns are added at defined coordinates to correct distortion. This matters on bottles, pouches, laminated badges, and any surface that introduces perspective or curvature. More modules create more risk of local distortion, so the standard compensates by adding more reference points.
Versions 7 and above also include version information areas encoded near two finder patterns. These bits let the scanner verify which version it is reading. Format information, which includes the error correction level and mask pattern, appears in all versions. Masking is another overlooked but essential concept. The generator applies one of eight mask patterns to avoid problematic visual artifacts such as large blank areas or repeating blocks that can confuse decoders. Good libraries automatically score and select the best mask.
Developers working with ZXing, ZBar, Nayuki libraries, or commercial SDKs such as Scandit and Dynamsoft generally do not need to place these patterns manually, but they do need to understand why a code grew to a certain version and why custom styling can break it. Rounded modules, embedded logos, gradients, and inverted colors reduce tolerance. Once density rises, decorative modifications become much less forgiving.
QR Code standards and formats beyond version numbers
When people discuss QR Code standards and formats, version numbers are only one part of the taxonomy. There is also a distinction between Model 1 and Model 2, with Model 2 being the modern mainstream implementation used by virtually all generators and scanners today. Model 1 was the earlier design and is rarely relevant in current production systems. Most teams can treat “QR Code” as referring to Model 2 unless they are maintaining legacy equipment.
Micro QR is another format often confused with low-numbered versions. It is not Version 0 or a subset of the main version ladder. It is a separate compact format intended for very small marking areas, using fewer finder and structural elements than a full QR code. It offers less capacity but can be ideal for tiny components or space-constrained labels. There is also rMQR, a rectangular variant standardized later for narrow spaces, and FrameQR, designed to reserve a canvas area. These are format choices, not full-version substitutions.
This matters for hub-level understanding because a team choosing between full QR, Micro QR, or rectangular alternatives should not jump straight to Version 1–40 comparisons. The first question is format fit. If the available space is extremely limited, a different QR family format may solve the problem more effectively than forcing a dense full-size version into a tiny area.
It also matters for interoperability. Standard smartphone camera apps overwhelmingly support mainstream Model 2 QR codes best. Specialized industrial scanners may support Micro QR and other variants more consistently. If your audience includes the general public, broad compatibility should outweigh theoretical compactness.
How to choose the right QR code version in real projects
The right version is the smallest one that meets your payload and resilience requirements under actual print and scanning conditions. Start by deciding whether the QR code should hold direct data or a short URL that points to dynamic content. For most public campaigns, dynamic QR management is the smarter route because it shortens the payload, lowers the version, and allows destination changes without reprinting materials.
Next, define the scanning environment. Will users scan from phone cameras at arm’s length, from vehicle mounts in warehouses, or from fixed-mount imagers on production lines? Consumer smartphone cameras handle low to moderate density well, but glare, distance, and motion quickly expose weak designs. Industrial imagers are better, yet even they perform best when module size, contrast ratio, and quiet zone are preserved.
Then test with representative devices. I never treat generator output as final until the code has been printed on the actual substrate and scanned under realistic lighting. A matte thermal label behaves differently from UV varnish on retail packaging. ISO/IEC 15415 print quality grading can help in controlled environments, and verifiers from vendors such as Axicon, REA, and Cognex provide measurable feedback on symbol contrast, modulation, axial non-uniformity, and defects. Those metrics are especially valuable when a higher version is unavoidable.
A practical rule is to optimize for module size first, then capacity. If the content forces a high version, consider compressing data, shortening URLs, moving lookup fields to a database, or revising the workflow. The cleanest QR implementation is usually the one that stores less, not more.
QR code versions 1–40 give the technology its standardized scalability, but the version number should never be chosen in isolation. It defines the internal grid, influences alignment and metadata placement, and works together with error correction and data mode to determine practical capacity. Once you understand that version means matrix complexity rather than physical dimensions, QR design decisions become much clearer.
The most important lesson is simple: use the lowest version that reliably fits the job. Lower-density symbols scan faster, survive real-world printing better, and leave more room for design tolerance. Higher versions have valid uses in industrial, offline, and security-sensitive workflows, but they are specialized tools, not defaults. In everyday customer-facing deployments, short payloads and strong redirect architecture usually outperform dense direct encoding.
As the hub for QR Code standards and formats, this page should serve as your baseline reference before diving into deeper topics such as error correction levels, Micro QR, print quality grading, static versus dynamic payload design, and scanner compatibility. If you are building or auditing a QR implementation, start by mapping the payload, environment, and format choice, then verify whether your selected version is truly necessary. That process will improve scan performance, reduce production risk, and lead to better QR code systems overall.
Frequently Asked Questions
What does a QR code “version” actually mean?
A QR code version is the standardized size class of the symbol. It tells you how many modules, or tiny square cells, the code contains across and down. Version 1 is the smallest standard QR code at 21×21 modules, and each step up adds 4 modules per side. That means Version 2 is 25×25, Version 3 is 29×29, and so on until Version 40, which reaches 177×177 modules. When people hear “version,” they sometimes assume it refers to software generation or compatibility, but in QR code terminology it specifically refers to the physical matrix size of the code.
This matters because the version directly affects how much data the QR code can store and how demanding it is to print and scan accurately. A larger version can hold more content, but it also becomes visually denser because more modules must fit into the same physical area if the printed size does not increase. In practical terms, version is one of the main design and implementation decisions behind a QR code. It influences readability, minimum print size, margin requirements, and overall user experience.
How do QR code versions 1–40 affect data capacity?
Version is one of the biggest factors that determines how much information a QR code can hold. As the version number increases, the grid becomes larger, which creates room for more encoded data. However, capacity is not determined by version alone. It also depends on the data type being encoded, such as numeric-only content, alphanumeric text, binary data, or kanji, and on the level of error correction selected. A lower error correction level leaves more space for payload data, while a higher error correction level reserves more space so the code can still scan even if part of it is damaged or obscured.
In real-world use, this means two QR codes with the same version can have different capacities depending on what they contain. A short numeric string may fit in a much smaller version than a long URL with tracking parameters, a vCard, or Wi-Fi credentials. That is why implementation teams should avoid thinking of version as a simple “small versus large” label. Instead, it should be treated as part of a balancing act between payload length, resiliency, and physical usability. The best practice is usually to keep the data as short as possible so the code can remain in a lower version, which often improves scan performance and gives more flexibility for printing and display.
Does a larger QR code version make scanning better or worse?
Not automatically. A larger version can hold more data, but it can also become harder to scan if the code is printed or displayed too small. The reason is simple: as version increases, the number of modules increases. If the overall physical size stays the same, each module becomes smaller. Tiny modules are more vulnerable to blur, low-resolution printing, glare, motion, screen pixel limitations, and camera autofocus issues. So while a higher version offers more capacity, it can reduce scan reliability when the output size is constrained.
In practice, scan performance depends on the relationship between version, physical size, contrast, error correction, quiet zone, and scanning conditions. A Version 4 QR code printed clearly at a reasonable size may scan much more reliably than a cramped Version 15 code holding an oversized URL. This is why experienced teams usually optimize the content first, then test the smallest practical version that preserves reliable scanning across real devices and environments. If the code will appear on packaging, signage, labels, or mobile screens, field testing matters more than theoretical capacity. A QR code is successful when it scans quickly and consistently, not when it uses the highest version possible.
How do QR code versions influence print size and design requirements?
The version has a direct impact on how large the final QR code should be when printed or displayed. Higher versions contain more modules, so they generally need more physical space to keep each module large enough for scanners to distinguish cleanly. This is especially important in printing, where ink spread, substrate texture, low contrast, or production variation can make dense QR codes harder to read. A code that works perfectly on a high-resolution monitor may fail once reduced onto a small label or printed on corrugated packaging.
Design requirements also go beyond the symbol itself. Every QR code needs a quiet zone, which is the empty margin around the code that helps scanners detect its boundaries. If a high-version QR code is placed too close to text, borders, patterns, or graphics, scan performance can drop sharply. The same is true if branding elements, logos, or custom styling remove too much contrast or interfere with the data area. For that reason, version choice should always be considered together with final placement, print method, material, and viewing distance. A strong implementation is not just about fitting the data into the code; it is about making sure the code survives real production conditions and still scans instantly.
How should I choose the right QR code version for a real project?
The best approach is to choose the smallest version that can comfortably hold your content at the required error correction level while still scanning reliably in the intended environment. Start by minimizing the payload. Use short URLs instead of long destination links, remove unnecessary parameters, and avoid packing in more data than users actually need. Once the payload is optimized, generate the code and evaluate what version is required. In many cases, keeping the code smaller in terms of version leads to a better result because the modules remain larger and easier to scan.
Then consider the context of use. A code on retail packaging, a restaurant table tent, an industrial label, and a mobile app screen all have different constraints. Print size, expected scanning distance, lighting, camera quality, movement, and potential wear all matter. If the code may be scratched, curved, or partially obstructed, a higher error correction level may be more important than maximizing capacity, even if that pushes the version upward. The key is not to choose a version in isolation. Choose it as part of a broader implementation decision that includes data length, output size, material, and testing. The right QR code version is the one that delivers dependable scans under real conditions, not simply the one that holds the most data.
