QR Code Size Requirements and Best Practices

8 min17 maja 2026

QR Code Size Requirements: The Basics

QR code size requirements depend on two factors: the amount of data encoded and the scanning distance. A QR code is a grid of black and white modules (squares). The smallest QR code (Version 1) is 21×21 modules and holds up to 25 alphanumeric characters. The largest (Version 40) is 177×177 modules and holds up to 4,296 alphanumeric characters. More data = more modules = larger physical size needed for reliable scanning.

The minimum physical size for reliable scanning is determined by the module size — each individual square must be large enough for the camera to resolve it. For smartphone scanning at arm's length (~25 cm), each module needs to be at least 0.33 mm. A Version 1 code (21 modules + 8 modules quiet zone = 29 modules wide) needs to be at least 10 mm × 10 mm. A Version 10 code (57 modules) needs at least 25 mm × 25 mm.

For print materials, I use this rule of thumb: the QR code should be at least 2 cm × 2 cm (0.8 inches) for business cards and close-range scanning, 3-4 cm for product packaging, and 10+ cm for posters or signage meant to be scanned from a distance. The scanning distance is roughly 10× the QR code width — a 3 cm code can be scanned from about 30 cm away.

Error Correction Levels (L, M, Q, H)

QR codes have built-in error correction using Reed-Solomon codes. This means part of the code can be damaged or obscured and it still scans. There are four levels: L (Low, 7% recovery), M (Medium, 15% recovery), Q (Quartile, 25% recovery), and H (High, 30% recovery). Higher error correction means more redundant data, which means more modules, which means a larger code for the same content.

The tradeoff is real. A URL like "https://example.com/page" at Level L produces a Version 2 code (25×25 modules). The same URL at Level H produces a Version 4 code (33×33 modules) — 74% more modules for the same data. For a clean, flat surface (screen display, fresh print), Level L or M is fine. For environments where the code might get dirty, scratched, or partially covered (product packaging, outdoor signage, warehouse labels), use Q or H.

The error correction is what allows logos in the center of QR codes. When you place a logo over the code, you're deliberately damaging those modules. With Level H (30% recovery), you can cover up to 30% of the code area and it still scans — but in practice, keep logos under 15-20% because the damage isn't evenly distributed. The three large position markers (corners) and alignment patterns must remain unobstructed.

My recommendation for most use cases: Level M (15%). It handles minor print imperfections and slight damage while keeping the code compact. Use Level H only when you need a logo overlay or expect physical damage. Use Level L only when you're optimizing for the smallest possible code size (screen-to-screen scanning in controlled environments).

Data Capacity and Content Limits

Maximum capacity at Level L: 7,089 numeric characters, 4,296 alphanumeric characters, or 2,953 bytes of binary data. At Level H, these drop to 3,057 numeric, 1,852 alphanumeric, or 1,273 bytes. In practice, you rarely approach these limits because larger codes are harder to scan reliably.

For URLs (the most common QR code content), keep them under 100 characters. A 100-character URL at Level M produces a Version 7 code (45×45 modules) — still very scannable. A 300-character URL produces a Version 13 code (69×69 modules) — getting large. If your URL is long, use a URL shortener or redirect service. The QR code doesn't care about the destination — it just encodes the text you give it.

Encoding modes affect capacity. QR codes automatically choose the most efficient encoding: Numeric mode (0-9 only, 3.3 bits per character), Alphanumeric mode (0-9, A-Z, space, $%*+-./:, 5.5 bits per character), Byte mode (any UTF-8, 8 bits per character). Uppercase URLs encode more efficiently than lowercase because they fit in Alphanumeric mode. "HTTPS://EXAMPLE.COM" uses fewer modules than "https://example.com" — a trick worth knowing for size-constrained codes.

One gotcha: WiFi QR codes (WIFI:T:WPA;S:NetworkName;P:Password;;) can get large if the password is long. A 63-character WPA2 password in a WiFi QR code produces a Version 8 code. If you're generating WiFi codes for a business, keep the password reasonable or use our qr-code-generator tool to preview the size before printing.

QR Code Version vs Capacity (Error Correction Level M):

Version  Modules   Alphanumeric   Typical Use
  1      21×21         20         Short URL (bit.ly/abc)
  2      25×25         38         Medium URL
  3      29×29         61         Full URL (no params)
  4      33×33         90         URL with short params
  5      37×37        122         URL with medium params
  7      45×45        196         Long URL or vCard
 10      57×57        311         Full vCard
 14      73×73        489         Large text block
 20      97×97        858         Very large payload
 40     177×177      2,331        Maximum (rarely used)

Rule of thumb: Stay under Version 10 for reliable scanning.
Anything above Version 15 requires close-range, high-res cameras.

Design Mistakes That Kill Scannability

Mistake 1: Insufficient quiet zone. QR codes need a white border (quiet zone) of at least 4 modules on all sides. This helps scanners distinguish the code from surrounding content. Cropping the quiet zone or placing the code against a busy background is the #1 reason codes fail to scan. I've seen marketing teams trim the border to "save space" and then wonder why 30% of users can't scan it.

Mistake 2: Low contrast. QR codes work best with maximum contrast — black modules on white background. Dark blue on light blue, or dark gray on medium gray, reduces the scanner's ability to distinguish modules. The ISO 18004 standard requires a minimum contrast ratio, but many phone cameras struggle below 40% contrast. Stick to black-on-white or very dark color on white.

Mistake 3: Inverting colors. White modules on black background (inverted QR code) technically works with most modern scanners, but older phones and some dedicated scanners fail on inverted codes. If you must use a dark background, keep the QR code in a white rectangle with proper quiet zone rather than inverting the code itself.

Mistake 4: Printing too small for the scanning distance. A 1.5 cm QR code on a conference banner meant to be scanned from 3 meters away will never work. The rule: scanning distance ≈ 10× code width. For a 3-meter scanning distance, you need a code at least 30 cm wide. I've seen this mistake on highway billboards (code too small), restaurant table tents (code in a dark corner), and event badges (code printed over a photo background).

QR Codes for Different Use Cases

URLs: The most common use. Encode the full URL including https://. Don't encode a URL shortener unless you control it permanently — if the shortener service dies, every printed code becomes useless. For tracking, add UTM parameters: https://example.com/page?utm_source=qr&utm_medium=print&utm_campaign=flyer2026. URL-encode any special characters in parameters (our url-encoder tool helps with this).

WiFi credentials: Format is WIFI:T:WPA;S:NetworkName;P:Password;H:false;; where T is security type (WPA, WEP, or nopass), S is SSID, P is password, and H indicates hidden network. Both iOS and Android recognize this format and offer to connect automatically. Great for guest networks in offices, hotels, and cafes.

vCards (contact info): The vCard format (BEGIN:VCARD...END:VCARD) encodes name, phone, email, address, and company. These get large quickly — a full vCard with address can be 300+ characters, requiring a Version 10+ code. Keep it minimal: name, phone, email. Let people look up the rest.

Payment: Different regions use different standards. China uses Alipay/WeChat Pay QR formats. Europe uses EPC QR codes for SEPA transfers. India uses UPI QR codes. Brazil uses PIX. There's no universal payment QR standard — you need to generate the format your target audience's payment apps expect. Don't assume a URL to a payment page is sufficient; native payment QR codes trigger the payment flow directly.

Dynamic vs Static QR Codes

A static QR code encodes the final content directly. Change the destination and you need a new code. A dynamic QR code encodes a short redirect URL (like qr.example.com/abc123) that you can update to point anywhere. The QR code itself never changes, but the destination can be updated after printing.

Dynamic codes are smaller (short redirect URL = fewer modules) and trackable (the redirect server logs scan counts, locations, devices). The downside: they depend on the redirect service staying online. If the service goes down or the company shuts down, every printed code breaks. I've seen this happen with QR code services that pivoted or went bankrupt — thousands of printed materials became useless overnight.

My recommendation: use static codes for permanent content (your website URL, WiFi password, contact info). Use dynamic codes only when you genuinely need to change the destination after printing (A/B testing landing pages, seasonal promotions, content that updates regularly). For tracking without dynamic codes, use UTM parameters in a static URL — you get analytics without the single-point-of-failure risk.

Cost consideration: most dynamic QR code services charge monthly fees ($15-50/month for business plans). If you have 100 codes across printed materials, that's a recurring cost forever. A static code pointing to your own domain costs nothing after printing. If you need dynamic behavior, consider hosting your own redirect service — it's a trivial application (a database mapping short codes to URLs) that you control permanently.

Testing QR Codes Before Printing

Always test with at least 3 different phones before sending to print. Test with: an older phone (iPhone SE or budget Android — slower cameras, lower resolution), a current flagship (to confirm it works in ideal conditions), and a phone with a cracked or dirty screen protector (simulates real-world conditions). If all three scan reliably at the intended distance, you're good.

Print a test at actual size on your office printer before ordering the full run. Inkjet and laser printers handle fine details differently, and the paper texture affects contrast. Glossy paper can cause glare that interferes with scanning under certain lighting. Matte paper is generally safer for QR codes.

Test the encoded content, not just the scannability. I once printed 5,000 flyers with a QR code that scanned perfectly — but the URL had a typo. The code worked fine; it just went to a 404 page. Scan the final code, follow the link, and verify the destination loads correctly on mobile. Check that any tracking parameters are captured correctly in your analytics.

For large print runs (10,000+ pieces), request a proof from the printer and test the proof. Commercial printing processes (offset, digital) can produce slightly different results than your office printer. Module edges might bleed slightly, reducing contrast. A code that scans fine on your laser printer might fail on a commercial offset press if the modules are at the minimum viable size.