40 QR Code Versions for Developers: Spec, Sizing, and Lifecycle

There are 40 standard QR Code versions, and version n has (17 + 4 × n) modules per side. Version 1 measures 21×21 modules; Version 40 measures 177×177. The version number tells you the symbol size, but actual data capacity depends on two other factors: the encoding mode you choose and the error-correction level you apply.

TL;DR:

• The maximum data capacity at Version 40 varies significantly depending on encoding mode, with up to 7,089 numeric characters at the lowest error correction level.
• Choosing a higher error-correction level reduces payload capacity and may require a larger version, especially for small payloads like URLs or text.
• Selecting the smallest compatible version involves assessing data mode, error correction, and payload length, rather than guessing or using a fixed size.
• Variants like Micro QR, Model 1, and proprietary formats exist but are niche, while Model 2 remains the standard choice for most applications.
• Real-world scan success depends on physical sizing, module pitch, quiet zones, and lighting, not solely on the version or capacity.

Table of Contents

• 1. Version numbers and their module counts
• 2. How capacity depends on encoding mode and error correction
• 3. Choosing the smallest version for your payload
• 4. Micro QR, Model 1, rMQR and other format variants
• 5. Translating module counts into physical, scannable dimensions
• 6. Why version choice matters for long-running campaigns
• 7. What developers should actually prioritise
• Where QRlytics fits once you’ve chosen a version
• Sources
• FAQ

1. Version numbers and their module counts

The formula behind every QR Code’s physical grid is simple: modules per side equals 17 plus 4 times the version number. Version 1 gives you 17 + 4 = 21 modules per side. Push that to Version 40 and you get 17 + 160 = 177 modules per side, the largest standard symbol defined by ISO/IEC 18004:2024.

That linear relationship makes it easy to calculate module counts for any version without consulting a lookup table, though having reference points helps when you’re validating an encoder’s output.

Every version from 1 to 40 belongs to Model 2, the modern standard that superseded the earlier Model 1 format. Model 1 topped out at Version 14 (73×73 modules) and lacks several alignment and timing features that Model 2 relies on for reliable decoding, so production encoders default to Model 2 without exception.

2. How capacity depends on encoding mode and error correction

Module count sets the ceiling on how much data a symbol can hold, but the actual number of characters you can pack in depends heavily on encoding mode. Numeric data is the most efficient, alphanumeric next, then byte encoding, with Kanji sitting in its own compact tier for double-byte characters.

At Version 40 with the lowest error-correction level, published maxima are:

• 7,089 characters for pure numeric data
• 4,296 characters for alphanumeric data (digits, uppercase letters, a limited symbol set)
• 2,953 bytes for byte-mode data such as UTF-8 text or binary
• 1,817 characters for Kanji encoding

The four error-correction levels trade capacity for recoverability. Level L recovers around 7% of damaged codewords, M around 15%, Q around 25%, and H around 30%. Choosing H over L on the same payload can push you up several versions, since more of the symbol’s data capacity is spent on redundancy rather than payload.

Consider a 200-character URL. At ECC level L it might fit comfortably into Version 9 or 10. Push the same string to ECC level H and you could need Version 12 or higher, purely because the correction overhead consumes more modules. Encoding mode and ECC level, not the version number alone, decide whether your payload fits.

3. Choosing the smallest version for your payload

Picking the right version is a matter of working backwards from your data, not guessing at a size and hoping it fits. A short, methodical process avoids both wasted space and failed encodes.

1. Identify your encoding mode. Check whether your payload is purely numeric, alphanumeric, byte-based, or Kanji, since mixed-mode payloads (a URL with a numeric suffix, for instance) need segment-by-segment calculation.
2. Set your error-correction level. Choose L for controlled indoor environments with clean printing, or higher levels (Q or H) where the code will face wear, glare, or partial obstruction such as a logo overlay.
3. Match capacity to version. Consult the capacity tables and select the smallest version whose maximum for your mode and ECC level meets or exceeds your encoded length. For payloads beyond Version 40’s limit, structured append lets you split data across multiple linked symbols, though support varies across scanning software.

DENSO Wave’s own worked example illustrates this well: 100 numeric digits encoded at ECC level M fits into Version 3, a 29×29 module symbol. That’s a useful sanity check when you’re validating your own encoder’s version selection logic.

Pro Tip: Build a small test harness that encodes your typical payload at each ECC level and logs the resulting version, so you catch capacity surprises before a print run rather than after.

4. Micro QR, Model 1, rMQR and other format variants

Standard QR Code isn’t the only symbology in the family, and knowing when to reach for an alternative saves space or unlocks features the standard format doesn’t offer.

• Micro QR (M1 to M4) ranges from 11×11 to 17×17 modules, suited to labelling small components where a full QR Code won’t physically fit, though capacity is limited and not every scanner app supports it.
• Model 1 is the legacy predecessor, capped at Version 14 (73×73 modules), largely superseded by Model 2 in current production use.
• Model 2 is the standard covered throughout this piece, supporting the full Version 1 to 40 range.
• rMQR, FrameQR and iQR are proprietary or extended formats offering rectangular shapes or larger capacities, but they sit outside ISO/IEC 18004 and depend on scanner-specific support, so treat them as niche choices rather than defaults.

For anything reaching a general consumer audience through a standard camera app, Model 2 remains the dependable choice.

5. Translating module counts into physical, scannable dimensions

A version number and module count only describe a grid, not a printable object. Physical size is modules per side multiplied by module pitch, and you then add a quiet zone of at least four modules around the entire symbol.

• Take a Version 1 symbol (21 modules) printed at a practical minimum of around 0.17 millimetres per module: that gives roughly 3.57 millimetres across the data grid before the quiet zone is added.
• Larger versions demand proportionally larger module pitch to stay scannable, since higher module counts packed into the same physical space shrink each module below what most camera optics can resolve.
• Contrast, substrate texture, ambient lighting, and motion blur during the scan all affect whether a technically valid symbol actually decodes on the first attempt.

A capacity maximum on paper doesn’t guarantee a successful scan in the field. Print sizing, quiet zone integrity, and camera optics determine real-world reliability as much as the underlying version choice. Our guide to sizing QR codes for print covers the module-pitch-to-print-dimension conversion in more depth, including common proofing pitfalls.

6. Why version choice matters for long-running campaigns

Version and encoding choices don’t end at the design stage. A QR Code destined for a six-month print run, a shop window, or a product package needs to behave predictably long after it leaves your screen.

• Static codes bake the payload directly into the module pattern, so a longer URL pushes you to a higher version purely to fit the characters, with no way to shorten it after printing.
• Dynamic codes store a short redirect URL in the symbol and resolve the destination server-side, which keeps the printed version small and stable even if the underlying link changes.
• Broken destination links, expired hosting, and lost scan data are common operational failures that have nothing to do with version selection but everything to do with how the code is managed after launch.

QRlytics addresses this by keeping codes functional for the life of a subscription and pairing that permanence with real-time scan analytics, so a version chosen correctly on day one doesn’t get undermined by a broken redirect on day two hundred.

7. What developers should actually prioritise

The workflow that holds up in practice is short: pick the smallest version that fits your payload and ECC requirement, set a module pitch that respects your printer’s real resolution, then proof on the actual target device before committing to a print run. Theoretical capacity tables tell you what’s possible, not what will scan reliably in a dim stockroom or through a scratched phone screen.

Treat the error-correction guide and print sizing guidance as companions to this reference, and always test on hardware rather than trusting the spec sheet alone.

— The

Where QRlytics fits once you’ve chosen a version

Getting the version, encoding mode, and error-correction level right solves the technical half of the problem. Keeping that code working for the lifetime of a campaign is the other half, and it’s the half most free generators quietly fail at once a subscription lapses or a payment bounces.

QR code management platforms can guarantee that any code created during an active subscription keeps working permanently, even after cancellation, so a correctly sized Version 10 symbol on a packaging run doesn’t turn into a dead link six months later. Dynamic codes let you update the destination URL without touching the printed artwork, which matters when your carefully calculated static version would otherwise need reprinting every time a link changes. Some platforms offer real-time scan analytics, GDPR-compliant tracking, and global heatmaps, with onboarding that may not require a credit card. If you’re building for a campaign that needs to last, start with the free plan or generate your first dynamic QR code directly.

Sources

• ISO/IEC 18004:2024 - Information technology — Automatic identification and data capture techniques — QR code bar code symbology specification
• Qrcode

FAQ

How many versions of QR codes are there?

There are 40 standard QR Code versions, numbered 1 through 40, each defined by ISO/IEC 18004. Version 1 is 21×21 modules and Version 40 is 177×177 modules, with each step adding 4 modules per side.

What are the different types of QR codes?

The main families are standard QR Code (Versions 1 to 40, Model 2), the legacy Model 1 format, and Micro QR (M1 to M4) for constrained spaces. Beyond symbology, codes also split functionally into static (fixed data) and dynamic (redirect-based, editable after printing).

What is the latest version of a QR code?

Version 40 is the largest standard version, holding up to 7,089 numeric characters at the lowest error-correction level. The current governing specification is ISO/IEC 18004:2024, the most recent edition of the standard.

How do I know what type of QR code I have?

Count the modules per side and subtract 17, then divide by 4, to find the version number. Whether it’s static or dynamic depends on the underlying platform: a dynamic code typically resolves through a short redirect URL rather than encoding the full destination directly.

Recommended

• Stop Reprints: QR lifecycle management for marketers and operations
• Marketers: Test URL Length to Keep QR Codes Live Under 100 Characters
• QR code legacy support: what businesses need to know