QR Code Standards & Use Cases — The 2026 Reference

QR codes look simple — a square pattern of black and white squares — but the standard behind them (ISO/IEC 18004) is surprisingly rich. There are 40 different sizes, four error-correction levels, four encoding modes, and a long list of conventions for what data to put inside. Understanding these choices is the difference between a QR code that scans on the first try across every reader and one that fails silently on Android while working on iOS.

Versions: the size of the code

A QR code's "version" is its grid size, ranging from 1 (21×21 modules) to 40 (177×177 modules). Each version up adds 4 modules per side and roughly doubles the data capacity. Version 1 holds about 25 alphanumeric characters at the safest error-correction level; version 10 (57×57 modules) holds about 200; version 40 (the biggest) holds about 4,000.

Bigger versions are not better. They have more modules, which means each module is physically smaller for the same printed size. A version 25 code printed at the size of a business card has modules so small that camera autofocus struggles to resolve them. The practical rule is: use the smallest version that fits your data.

Error correction: damage tolerance

QR codes use Reed-Solomon error correction. Four levels are defined:

• L (Low): ~7% of modules can be unreadable. Smallest payload overhead. Good for clean digital displays.
• M (Medium): ~15%. The default for most generators. Good general-purpose choice.
• Q (Quartile): ~25%. Use when the code might be partially obscured or printed on rough material.
• H (High): ~30%. Required for codes with a logo overlay (the logo covers some modules; H lets you lose them and still scan).

Higher correction means more redundancy, which means larger version for the same payload. A logo overlay is the most common reason to use H. Without a logo, M is usually fine.

Encoding modes

The standard defines four modes optimised for different content types:

• Numeric: digits 0–9 only. Most efficient. 10 digits per 33 bits.
• Alphanumeric: digits, uppercase letters, and a few symbols ($%*+-./:). Used for short URLs that have been deliberately uppercased to fit this mode.
• Byte: raw bytes, typically UTF-8. Used for everything that doesn't fit the simpler modes — mixed-case text, non-ASCII characters, structured data.
• Kanji: 13-bit encoding for Japanese characters. Rarely used outside Japan.

A good generator chooses the mode automatically based on the content. The size difference matters: a URL like https://toolkiya.com/some-tool in alphanumeric mode (uppercase) takes about 30% fewer modules than the same URL in byte mode (mixed case).

Payload conventions

QR codes don't have a built-in concept of "type." Whatever bytes you put in, the scanner reads back. Convention has filled the gap with a set of textual prefixes that scanners recognise and act on. The major ones:

URL

Just the URL itself, including the scheme: https://toolkiya.com. Without the scheme, scanners often interpret it as plain text and just display it without offering to open the browser. Always include https://.

vCard (contact card)

A multi-line vCard 3.0 payload. Modern phones recognise this and offer to add the contact directly. The payload looks like:

BEGIN:VCARD
VERSION:3.0
FN:Mayank Rai
TEL:+91-9876543210
EMAIL:hello@toolkiya.com
URL:https://toolkiya.com
END:VCARD

Field order matters — most parsers expect FN before structured fields. Avoid version 4.0; not all phones parse it correctly yet.

WiFi credentials

The format is WIFI:T:WPA;S:network-name;P:password;;. The trailing two semicolons are required. Special characters in the password (semicolons, backslashes, commas) must be backslash-escaped. iOS and recent Android both support this, with the user prompted to confirm before joining.

UPI (India payments)

UPI uses a URL scheme: upi://pay?pa=merchant@bank&pn=Merchant%20Name&am=100&cu=INR. The receiving app reads the parameters and pre-fills the payment screen. The merchant's VPA (the pa parameter) must be valid; the rest are conveniences.

Plain text

If the payload doesn't match a recognised pattern, scanners just display it as text. Useful for short messages, codes, ticket numbers.

Quiet zone — the most common mistake

The QR specification requires a 4-module-wide white border around the code (the "quiet zone"). When designers crop a QR code tight against other content, scanners struggle to find it. A QR code printed flush against the edge of a poster or with text running right up to its border is much harder to scan than the same code with proper margins. Always leave the quiet zone.

Colour and contrast

The standard says "dark on light." The dark modules need to be measurably darker than the light modules from the camera's point of view. Most scanners want at least 40% luminance difference. Black on white is the safest choice; pure black on pure white is overkill but hurts nothing.

Inverting the code (light modules on dark) is non-standard and many scanners reject it. Coloured codes work as long as contrast is preserved — dark blue on cream, dark green on light beige. What does not work is similar luminance: red on green, navy on dark grey, light orange on light yellow. The fact that humans can read coloured text does not mean a QR scanner can.

Logo overlays

Adding a logo in the centre of a QR code is a common branding move. It works because the centre of the code carries less critical data (the corners hold the position-detection patterns, which are essential). With error correction set to H, you can cover up to ~25% of the modules with a logo and still scan reliably.

Practical guidelines: keep the logo to under 20% of the code area, centred. Use a solid white square behind the logo so the scanner sees a clear boundary. Test scan from multiple angles and distances before printing. A logo that looks fine on screen sometimes pushes a code over the threshold of unreadability.

Print size

For reliable scanning, each module needs to be at least 0.5 mm at the smallest expected scan distance. The rule of thumb: code size in cm should be at least one-tenth of the scan distance in cm. A code intended to be scanned from 30 cm away should be at least 3 cm × 3 cm. A poster code intended for scanning from 3 metres needs to be 30 cm × 30 cm.

Dynamic vs static

A static QR code embeds the destination directly. A dynamic QR code embeds a short tracking URL that redirects to the real destination, allowing the destination to be changed later without reprinting. Dynamic codes have advantages — analytics, the ability to fix typos in the destination URL — but they introduce a dependency on the dynamic-QR provider. If the provider goes out of business, every code printed with their service stops working.

For long-lived physical materials (signage, business cards, packaging) static codes are safer. For short campaigns where you genuinely need analytics, dynamic codes are reasonable, but pick a provider with a long track record.

Generating reliable codes

Toolkiya's QR generator picks the right version, error-correction level, and encoding mode automatically based on what you put in. Everything happens in your browser — no payload is uploaded to any server. For payment codes, vCards, and WiFi credentials this matters: the data inside the code is often sensitive, and it should never leave your device.

Whatever tool you use, test the result with multiple scanners (iPhone Camera, Android Camera, Google Lens, a third-party scanner app) before committing to print. A QR code that fails to scan on a customer's phone is worse than no QR code at all.