QR Code Versions Explained: From V1 (21×21) to V40 (177×177)
Key Takeaway
Every QR code is one of 40 versions defined by ISO/IEC 18004. Capacity tables for V1 through V40, the module-count math, and how to pick the right version for your data and scan distance. 2026.
Every QR code is one of 40 versions defined by the ISO/IEC 18004 standard. Version 1 is a 21×21-module grid; each next version adds 4 modules per side. Version 40 is the largest, at 177×177 modules. The version controls capacity (how much data the symbol holds), physical size (how big the symbol gets at a given module resolution), and scan range (how far away a phone can read it).
This guide is the practical companion to the spec post. It covers: how many characters each version holds, how to pick the right version for your data, and the surprising ways a smaller version often outperforms a larger one in real-world scanning.
The module-count math
The relationship between version and grid size is simple: modules per side = 17 + 4 × version. So Version 1 is 21×21 (17 + 4 × 1 = 21), Version 10 is 57×57 (17 + 40 = 57), and Version 40 is 177×177 (17 + 160 = 177). Each version step adds 4 modules to each side — never 2, never 6.
The number of modules per side determines two things downstream: how much data the symbol can encode (capacity grows roughly quadratically with version), and how physically large the symbol needs to be printed for a given scanner to resolve individual modules. A camera that can resolve 5 pixels per module needs a 5× larger print for V40 than for V1.
Why does the +4 rule exist? Two reasons baked into the standard: first, the alignment-pattern grid (covered below) is laid out on a regular spacing that aligns naturally with 4-module steps. Second, each version step has to leave room for the version-information bit block (V7+) and for the standard's prescribed positions of format-info and timing patterns. Smaller increments would break those layout assumptions; larger increments would create gaps in capacity coverage. The +4 step is a deliberate engineering compromise, not a coincidence.
Capacity by version — the numbers that actually matter
The table below shows maximum characters at error-correction level M (the most common default) for the four encoding modes. Level L gives ~20% more capacity; level H gives ~40% less.
| Version | Grid | Numeric | Alphanumeric | Byte (Latin-1) | Kanji |
|---|---|---|---|---|---|
| V1 | 21×21 | 34 | 20 | 14 | 8 |
| V2 | 25×25 | 63 | 38 | 26 | 16 |
| V3 | 29×29 | 101 | 61 | 42 | 26 |
| V4 | 33×33 | 149 | 90 | 62 | 38 |
| V5 | 37×37 | 202 | 122 | 84 | 52 |
| V10 | 57×57 | 513 | 311 | 213 | 131 |
| V15 | 77×77 | 868 | 526 | 361 | 222 |
| V20 | 97×97 | 1316 | 797 | 547 | 338 |
| V25 | 117×117 | 1853 | 1123 | 770 | 475 |
| V30 | 137×137 | 2521 | 1528 | 1050 | 647 |
| V35 | 157×157 | 3220 | 1951 | 1339 | 824 |
| V40 | 177×177 | 4296 | 2603 | 1852 | 1273 |
Capacity figures come directly from Table 7 of ISO/IEC 18004. For the full table across all four error-correction levels, see the Denso Wave version table.
Which version fits your data?
A typical short URL — say 'https://qrlynx.com/r/Abc123' at 29 characters — fits in Version 2 (V2) with error-correction level M. A long URL with UTM parameters — say 150 characters — needs Version 7 or so. A vCard contact with name, multiple phones, email, and a longish job title typically lands in V10–V15.
Rough guidance for picking a version:
- Under 100 characters: V1–V5. Easiest to scan from any distance.
- 100–500 characters: V6–V12. Still scan well at typical phone distances.
- 500–1500 characters: V13–V25. Phones may need a closer hold; consider whether the data should live behind a dynamic QR redirect instead.
- 1500+ characters: V26–V40. Almost always the wrong choice for a print-and-scan workflow — print resolution and camera capability become the binding constraint. A dynamic QR pointing at a hosted vCard is faster and more reliable.
For most marketing and operational use-cases, you don't pick the version manually — the generator picks the smallest version that holds your data at your chosen error-correction level. The version becomes a thing to think about only when you're fighting print-size constraints (poster billboards, sticker labels) or trying to embed a logo at high error-correction level H. In either of those scenarios, the version-capacity table above is the first place to look before deciding whether to trim the payload, lower the error-correction level, or switch to a dynamic redirect QR that keeps the symbol small regardless of destination size.
Why smaller versions usually scan better
Counter-intuitively, a smaller (lower-version) QR code is often easier to scan than a larger one printed at the same physical size. Two reasons:
- Module size and camera resolution. A V1 QR printed at 2cm × 2cm has 21 modules across, each ~0.95mm — well within smartphone camera resolving power even at 30cm away. A V20 at the same 2cm has 97 modules at ~0.21mm each — below the resolving threshold for many cameras unless held very close.
- Focus margin. Lower-version symbols tolerate more focus error. A V5 printed at 5cm × 5cm forgives a degree of camera blur that would render a V25 at the same size completely unreadable.
The practical implication: if your data fits in V1–V5 at the error-correction level you need, use it. Don't bloat the symbol unnecessarily. The QR code size calculator and print sizing guide both bake in the version-to-physical-size math.
A concrete worked example: suppose you're printing a QR on a business card (roughly 2.5cm × 2.5cm available). At V2 (25×25 modules) each module is 1mm; a decent phone camera resolves that cleanly at arm's length. At V20 (97×97 modules) each module shrinks to ~0.26mm — about half the resolving threshold of most smartphone cameras at the same distance. The same physical card becomes essentially unscannable not because the QR is invalid, but because the version exceeded the practical density budget for the print size. Pick the lowest version that fits your data, then size the print accordingly — never the other way around.
How the version is encoded into the symbol
Scanners need to know the version of a symbol before they can read its data. There are two ways the version is communicated, and they kick in at different sizes:
- Versions 1–6. The scanner infers the version from the distance between the three finder patterns. No explicit version bits are stored.
- Versions 7–40. The standard requires an explicit 18-bit version information block, placed near the top-right finder pattern. It includes 6 bits of version number plus 12 bits of BCH error-correction for that 6-bit value — so the scanner can still read the version even if some of those modules are damaged.
That redundancy in the version-info block is one of many quiet features that make QR codes robust. Even if a corner of a V20 symbol is torn, the scanner can still figure out it's a V20 symbol and run the appropriate decoding logic.
One historical note: the original 1994 Model 1 QR codes used a slightly different version-info scheme without the BCH error correction layer. The 1997 Model 2 update added BCH and increased the version-info to 18 bits — one of several backward-incompatible changes that effectively retired Model 1 from mainstream use. Every contemporary scanner expects Model 2 version encoding; if you're working with a legacy industrial library that produces Model 1 symbols, double-check that your downstream scanners support it before deploying.
Micro QR Code: a separate version system for tiny symbols
If your data is very short and you need the symbol as physically small as possible, the standard offers a separate symbol type called Micro QR Code. Micro QR codes have their own version system — M1, M2, M3, M4 — and use only one finder pattern instead of three. The trade-off is reduced capacity and reduced scanner compatibility.
| Micro version | Grid | Max numeric capacity | EC levels available |
|---|---|---|---|
| M1 | 11×11 | 5 digits | None (error detection only) |
| M2 | 13×13 | 10 digits | L |
| M3 | 15×15 | 23 digits | L, M |
| M4 | 17×17 | 35 digits | L, M, Q |
Micro QR is common in Japanese manufacturing (where it originated) and in tiny label applications like medical syringes, electronics components, and jewelry tags. Most general-purpose phone scanners read Micro QR, but support is meaningfully less universal than standard QR. For consumer-facing print campaigns, stick with standard QR Versions 1–5 even if your data would fit in a Micro QR.
Alignment patterns: the dots inside larger versions
Open a V1 QR and you'll see only the three finder patterns in three corners. Open a V10 or V20 and you'll see a scatter of smaller nested-square 'alignment patterns' across the symbol's interior. These appear from V2 onward and increase in count with version:
- V1: 0 alignment patterns (only the three finders)
- V2–V6: 1 alignment pattern in the bottom-right region
- V7–V13: 6 alignment patterns
- V14–V20: 13 alignment patterns
- V21–V27: 22 alignment patterns
- V28–V34: 33 alignment patterns
- V35–V40: 46 alignment patterns
These extra dots help the scanner correct for perspective distortion (camera tilt) and surface curvature — important for larger symbols where a small tilt at the corner translates to a big offset at the center. A V40 symbol photographed at a 15° angle on a curved wine bottle is still readable because the alignment patterns let the scanner unwarp the grid.
How to pick the right version for a real campaign
Encode your data and let the generator pick the version
Start by entering your data into a QR generator at the error-correction level you need (M for general, H if you'll embed a logo). The generator picks the smallest version that fits. Note that version — it's your floor.
Check the physical size constraint
Look at where the QR will be printed and how far away people will scan from. A poster scanned from 3 meters needs each module at least 3mm wide (roughly), which means the symbol needs to be at least 21 × 3mm = 63mm wide at V1. For larger versions, scale proportionally. The size calculator linked above bakes in the ISO sizing rules.
If the symbol is too big to print at the required scan distance, go dynamic
If a static QR encoding all your data ends up too physically large to print, the answer isn't a higher-version static QR — it's a dynamic QR pointing at a hosted page. Dynamic QRs are typically V2–V5 regardless of destination content size.
Test on a real phone before printing at scale
Print one symbol at the target size, attach it to the target surface, and scan from the realistic distance and angle. Many usability problems only surface in physical test — wrinkled paper, glare, surface curvature, ambient light. The cost of testing one print is trivial; the cost of reprinting 10,000 unreadable QRs is not.
Frequently Asked Questions
Are versions and error-correction levels the same thing?
No. Version controls the symbol's grid size (V1 is 21×21, V40 is 177×177). Error-correction level controls how much of each grid is redundancy versus data (L 7%, M 15%, Q 25%, H 30%). You set them independently; the generator might bump the version up if your chosen error-correction level doesn't leave enough room for your data.
Why does the version matter if scanners handle it automatically?
Two practical reasons: print size and scan distance. Larger versions need more physical space to remain scannable. If your design constraint is 'must fit in a 1-inch label' or 'must scan from 5 meters away,' the version determines whether your data plan is feasible at all.
Is there ever a reason to manually force a higher version than needed?
Occasionally. Some industrial and security applications use Structured Append (splitting data across multiple symbols) where each symbol is forced to a specific version for consistency. Otherwise, smaller is always better for scannability.
What's the smallest QR that holds a typical URL?
For URLs under 25 characters in length (a typical short link like https://qrlynx.com/abc), V2 at error-correction M is sufficient. For URLs up to 50 characters, V3. UTM-tagged URLs of 100+ characters need V5–V7. Smart generators always pick the smallest version that fits.
How does the version affect logo embedding?
Logo embedding requires error-correction level Q or H (which sacrifice 25-30% of data capacity to redundancy bytes). At the same version, switching from M to H roughly halves the available data capacity. So embedding a logo typically pushes the version up by 2–4 steps for the same data. The QRLynx logo overlay tool handles this automatically.
Can different scanners disagree about which version a symbol is?
No — the version is unambiguous from the symbol structure. For V1–V6 it's determined by finder-pattern spacing; for V7–V40 by the explicit version-info bit block. A standards-compliant scanner will compute the same version for the same symbol every time.
What's the difference between QR version and QR Model?
Model refers to the symbology variant (Model 1, Model 2, Micro QR, iQR Code — all defined in ISO/IEC 18004). Version refers to the grid size within a model (V1 through V40 for Model 2; M1 through M4 for Micro QR). Almost every QR you scan in 2026 is a Model 2 symbol; the version varies by content.
Why does a vCard QR usually look bigger than a URL QR?
A vCard contains multiple fields — name, phone, email, organization, often a photo — that add up to several hundred bytes. That pushes the version up to V10–V20 territory, where the symbol has 4–8× more modules per side than a typical URL QR (V2–V5). If you need the contact card to scan small, use a dynamic QR pointing at a hosted vCard page or a Digital Business Card.
Does QRLynx let me pick the version manually?
By default, the generator picks the smallest version that fits your data at your chosen error-correction level — the right answer for almost every use case. Some advanced design templates may bump the version to accommodate stylistic constraints (e.g., a forced minimum module count for a specific design pattern). The version is always documented in the QR's metadata when you save or download.
What's the practical maximum data I should encode in a single static QR?
For something a phone camera at typical hand-holding distance will scan reliably, ~500 characters is a soft ceiling — corresponding to roughly V9 at error-correction M. Beyond that, scanning becomes finicky in real-world conditions. If your destination data exceeds 500 characters, switch to a dynamic QR pointing at a hosted page.
Where do the capacity numbers in this guide come from?
They're taken directly from the capacity tables in ISO/IEC 18004 (Table 7 and related). Denso Wave publishes the same numbers in their public version reference. For the full table with all four error-correction levels and all four encoding modes (160 cells total), consult either source.
Picking version isn't usually your problem — picking dynamic vs static is
The version question matters most when you've already decided on a static QR with a fixed payload. For most marketing and business use-cases, the better decision happens one level up: do you need a static QR or a dynamic one? A static QR encodes the destination directly into the symbol, so the version scales with payload size. A dynamic QR encodes a short redirect URL on your QR platform; the version stays small (typically V2–V5) regardless of where the redirect ultimately leads. Our static vs dynamic comparison covers that decision in depth.
Once you've picked dynamic, the version question essentially disappears — the QRLynx redirect URL on r.qrlynx.com produces a compact V2–V3 symbol that scans reliably from any reasonable distance, regardless of how complex the destination is. Add features like lead capture forms or analytics on top, and the version of the printed symbol is the same. The testing methodology documents how we measure version and scan reliability across the platforms we evaluate.
