QR Code Versions and Data Capacity: How Much Can One Code Hold?
Understand QR versions 1–40, module grids, numeric vs byte capacity, and how dynamic short URLs keep printed codes scannable at practical sizes.
A QR code is not one fixed square. Under ISO/IEC 18004 there are forty versions — forty discrete grid sizes — each able to store a different amount of data. Version 1 is a compact 21×21 module symbol; version 40 is a 177×177 grid that can hold thousands of characters. Everyday marketing codes sit somewhere between those extremes.
Version and capacity matter because payload length drives density, and density drives how large you must print for reliable scans. A short link can live in a low version and stay readable at a few centimeters. A long static URL, full vCard, or complex Wi‑Fi string may force a higher version: more modules in the same physical space until the camera struggles.
This guide is in the General silo. It focuses on how much data fits and which version that implies. For camera decoding, see how QR codes work. For how levels L/M/Q/H trade capacity for damage recovery, see QR code error correction explained — that article covers recovery; this one covers version and payload size.
What a “version” actually means
In QR terminology, version means grid size, not a software release. Each version adds four modules per side compared with the previous one:
| Version | Modules (side × side) | Rough role |
|---|---|---|
| 1 | 21×21 | Short payloads; tiny print possible |
| 2 | 25×25 | Slightly more room; still compact |
| 5 | 37×37 | Typical short URLs and simple text |
| 10 | 57×57 | Longer URLs, modest contact data |
| 20 | 97×97 | Large payloads; needs generous print |
| 40 | 177×177 | Maximum standard capacity |
Formula: side length = 21 + 4 × (version − 1). Version 1 → 21; version 2 → 25; …; version 40 → 177.
Not every module stores your message. Finder patterns, timing patterns, alignment patterns (from version 2 up), format information, and — on larger versions — version information occupy fixed positions. The remaining modules hold data and error-correction codewords. Two codes that look equally “busy” can still differ in useful payload size depending on version and error-correction level.
If you only need a one-line definition of the format, skim what a QR code is first, then return here for capacity planning.
Encoding modes: why the same text needs different space
Capacity tables always specify an encoding mode. More compact modes pack more characters into the same version.
Numeric mode
Digits 0–9 only. Most efficient for serials, phone numbers without punctuation, and short IDs. Three digits pack into about 10 bits — denser than treating each digit as a full byte.
Alphanumeric mode
Uppercase A–Z, digits, space, and a small symbol set ($ % * + - . / :). Useful for uppercase product codes. Mixed-case URLs usually force byte mode because of lowercase letters.
Byte mode
Eight-bit bytes — the default for modern web URLs, mixed-case text, and most UTF‑8 content. Flexible and common; less dense than numeric or alphanumeric for the same character count.
Kanji mode
Optimized for Japanese Shift JIS characters. Most Western marketing payloads never use it.
Practical takeaway: a 40-character numeric string may fit a smaller version than a 40-character byte URL. Generators pick the mode automatically; you still control the payload length that drives version selection. For how URL, Wi‑Fi, and vCard payloads differ, see types of QR codes: URL, Wi‑Fi, and vCard.
Capacity depends on mode and error correction together
Maximum character counts are published per version × mode × error-correction level. Higher correction (Q, H) reserves more of the grid for parity, so usable payload shrinks. Lower correction (L, then M) leaves more room for data.
That is the bridge to the error-correction guide: choosing H for a center logo is a recovery decision that also reduces capacity — and may bump you to a larger version if the URL is long. Choosing L maximizes capacity but leaves less margin for damage. The levels (~7% / ~15% / ~25% / ~30% recovery) are covered in QR code error correction explained; here, remember that H costs capacity.
Illustrative capacities (approximate)
Exact ISO tables are long; these rounded examples show the pattern. Always let a standards-compliant generator confirm what your exact string fits.
| Version | Numeric (L) | Alphanumeric (L) | Byte (L) | Byte (H) |
|---|---|---|---|---|
| 1 | ~41 | ~25 | ~17 | ~7 |
| 5 | ~255 | ~154 | ~106 | ~46 |
| 10 | ~652 | ~395 | ~271 | ~119 |
| 20 | ~2061 | ~1249 | ~858 | ~382 |
| 40 | ~7089 | ~4296 | ~2953 | ~1273 |
A short link of ~20–30 bytes can fit version 1–3 at medium correction. A 200-character tracking URL may need version 8–12 depending on level. A full multi-line vCard can push into double-digit versions quickly. Version 40 at level L holds thousands of bytes — rarely needed for marketing.
Why your generator “jumps” version
When you paste a longer URL or switch from M to H, the tool recalculates the smallest version that fits. The printed square may stay the same physical size while the module count rises — each module shrinks. Same sticker, finer grid, harder scan at a distance.
Why long static URLs densify codes
A static QR code stores the full payload in the modules. Encode a long campaign URL with UTM tags and every character (in byte mode) consumes capacity. Query parameters help analytics on your site — but they inflate the symbol.
Dense high-version codes fail more often when print size is small (business cards, hang tags), viewing distance is large (window posters), contrast or quiet zone is weak, or a logo covers center modules on top of a high version and high correction.
Compared with static vs dynamic QR codes, the static path locks both destination and length into the graphic. Fixing a typo or shortening a URL later means reprinting.
Why dynamic short redirects help print size
A dynamic QR code encodes a short redirect URL on a provider domain — often a few dozen characters — instead of the final long destination. The phone opens the short link; the server forwards the user to the current landing page.
That keeps the encoded payload small, so the generator can stay on a low version. Modules stay larger at the same print size, which improves scan reliability for packaging, menus, and outdoor signs.
You also gain operational flexibility: edit the destination after print, keep long UTM strings on the server side while the printed code stays short, and avoid cramming multiple destinations into one oversized static payload.
Izoukhai’s dynamic QR generator is a strong, low-cost option for this pattern: $3.99/month or $39.99/year, unlimited QR codes and scans, real-time analytics (scans, devices, locations), colors/shapes/frames/logo, SVG export, and destinations you can change anytime. Codes keep working after you cancel. Dynamic codes do not change the version formula; they change the string length you feed into it — short input → lower version → larger modules at a given size.
Practical size recommendations (version meets physical print)
Capacity is abstract until you pick a print size.
Module size, not just overall millimeters
Scanners need each module large enough to survive ink spread, camera focus, and distance. A common guideline is roughly 1.0–1.5 mm minimum module width for reliable handheld phone scans in good light — more for outdoor or damaged surfaces. Overall side length ≈ module size × modules per side (plus quiet zone).
Examples:
- Version 1 (21 modules) at ~1.2 mm/module → roughly 2.5 cm side before quiet zone.
- Version 10 (57 modules) at the same module size → roughly 7 cm side.
- Version 20 (97 modules) → often 10+ cm if modules stay ≥ ~1 mm.
If marketing insists on a 2 cm code on a hang tag, keep the version low (short payload, moderate correction) or accept scan failures.
Distance and placement
Farther viewers need larger overall symbols. A table tent can use a smaller version-3 code; a mall window needs a larger physical print even if the version is low. Capacity planning still starts with “how many modules am I asking the camera to resolve?” — see QR code contrast, size, and quiet zone for placement and contrast.
Logos and branding
Center logos consume module area and usually call for higher error correction — which reduces capacity and may increase version. Prefer short dynamic URLs when branding the code. See branding QR codes with logos and colors. Export vector artwork (SVG) when scaling for print so modules stay sharp — QR code file formats: SVG, PNG, and PDF.
When to shorten the payload vs enlarge the print
Shorten the payload when…
- The physical footprint is fixed (product label die-cut, business card corner).
- You need room for a logo or frame.
- You want Q/H correction without ballooning version.
- The URL is static but full of tracking parameters — move tracking to a short redirect or server-side analytics.
- Destinations change over time — one short dynamic code beats reprinting dense static variants.
Enlarge the print when…
- The payload cannot shrink (offline text, regulatory strings, complete Wi‑Fi credentials in-symbol).
- Viewing distance is large and you already use a short URL.
- Print is coarse (some corrugated or fabric) and modules need to be bigger regardless of version.
- You are already on a low version and still fail scans — the problem is size, contrast, or quiet zone, not capacity.
Combine both when…
- Dense vCard or long Wi‑Fi string: minimize fields, then print larger than a URL code of the same version would need.
- Heavy branding: short dynamic link + adequate print size + appropriate correction.
A workflow that works for most teams:
- Decide static vs dynamic (static vs dynamic QR codes).
- Minimize encoded characters (especially for static).
- Pick correction for environment/logo (error correction guide).
- Generate and note the version your tool selects.
- Size the print so modules stay ≥ ~1 mm (more if harsh conditions).
- Test on multiple phones before a full print run.
Capacity myths worth dropping
“Higher version is always better.” At a fixed print size, more modules mean smaller cells. Prefer the lowest version that fits your payload and correction level.
“Dynamic codes hold less data.” The encoded redirect is short; the landing page can be as rich as you like. Symbol capacity is about what is in the modules, not what the page contains.
“Version 40 means professional quality.” Version 40 means a huge payload. Quality usually means a low version, clear contrast, quiet zone, and a tested print size.
Putting it together for real campaigns
Menus, packaging, and event badges almost always win with short dynamic URLs, low versions, and print sizes matched to viewing distance. Serialization and offline instructions may need higher versions — budget physical space early so modules never become sub-millimeter specks.
When you generate codes, note the version and level. If the preview blurs at thumbnail size, shorten the data or enlarge the artboard. Prefer SVG for print scaling. For unlimited, editable, analytics-backed codes at $3.99/month or $39.99/year, try Izoukhai — including SVG export and destination edits after print.
Conclusion and next steps
QR version is the module grid (21×21 through 177×177). Capacity is how many characters fit after mode and error-correction overhead. Long static URLs push version up and modules down; dynamic short redirects reverse that pressure. Pair those choices with contrast, quiet zone, testing, and the right correction level for logos and wear.
Continue with how QR codes work, static vs dynamic QR codes, types of QR codes: URL, Wi‑Fi, and vCard, and NFC vs QR codes when you are choosing an offline-to-online medium rather than sizing a matrix. For production, use contrast, size, and quiet zone and file formats. To create short, editable codes with unlimited scans and post-cancel continuity, open Izoukhai’s QR product page.