How Do QR Codes Work? A Complete Technical Explanation for 2026

A QR code works by encoding data — such as a website URL — as a two-dimensional grid of black and white squares called modules. When your smartphone camera captures the code, it locates the code's orientation using three square markers, reads the module pattern as binary data (black = 1, white = 0), applies error-correction algorithms to reconstruct any damaged bits, and decodes the result into your original text or URL — in under 100 milliseconds.

For dynamic QR codes (the professional standard), there is one extra step: your phone is redirected through a server. The code stores a short redirect URL like smllr.app/abc rather than the final destination directly. When scanned, SMLLR's edge server receives the request, looks up the current destination for that QR ID, logs the scan event, and sends your phone to the target page in under 200ms total. This is what makes dynamic QR codes updatable, trackable, and intelligent — without changing anything about the physical code.

If you want to understand the technical depth of how QR codes work — the finder patterns, encoding modes, Reed-Solomon error correction, and how SMLLR's routing layer adds intelligence on top — this guide covers every layer.

A QR code is not a random pattern of dots — it is a precisely engineered data structure. Every element serves a specific function in the scanning process:

Finder Patterns (Position Detection Patterns)
Three large square-within-square targets at the top-left, top-right, and bottom-left corners. The module-width ratio is always 1:1:3:1:1 (dark:light:dark:light:dark). This consistent ratio is detectable regardless of rotation, perspective distortion, or lighting conditions. When a scanner identifies this ratio in three corners, it knows it has found a QR code and can calculate orientation. No other barcode format uses this pattern, preventing false positives.

Separators
One-module-wide white borders isolating each finder pattern from the data region. Without separators, data modules near the corners would be mistaken for part of the finder patterns.

Timing Patterns
Alternating black-and-white lines running horizontally (between top-left and top-right finder patterns) and vertically (between top-left and bottom-left finder patterns). They establish the coordinate grid — the row and column framework the decoder uses to locate each individual module in the matrix.

Alignment Patterns
Small square targets distributed inside larger QR codes (Version 2 and above). They allow scanners to correct for perspective distortion when the code is photographed at an angle or printed on a curved surface like a bottle, can, or convex display.

Format Information Strips
Two 15-bit strips near the finder patterns that communicate: (a) the error correction level (L, M, Q, or H) and (b) the mask pattern number. This information is encoded redundantly in two locations so the scanner can read it even if one copy is damaged.

Version Information
For QR codes of Version 7 (45×45 modules) and above, additional 18-bit strips near two finder patterns specify the version number — telling the decoder the exact grid dimensions to expect.

Quiet Zone
A mandatory blank white border of at least 4 modules wide surrounding the entire code. Without this space, the scanner cannot determine where the code ends and the surrounding design begins. Violating the quiet zone requirement is one of the most common reasons professionally designed QR codes fail to scan.

Data and Error Correction Codewords
The remaining modules after all the structural elements — this is where your encoded URL or text lives, interleaved with Reed-Solomon error correction data.

QR codes exist in 40 numbered versions, each larger than the previous. The version number determines the grid size:

• Version 1: 21×21 modules — stores up to 41 numeric characters (at error correction Level L)
• Version 5: 37×37 modules — stores up to 154 alphanumeric characters
• Version 10: 57×57 modules — common size for marketing QR codes with medium-length URLs
• Version 20: 97×97 modules — stores complex data like full contact records
• Version 40: 177×177 modules — stores up to 7,089 numeric or 4,296 alphanumeric characters

When you generate a QR code, the version is chosen automatically based on how much data you're encoding and what error correction level you've selected. More data or higher error correction = higher version = larger, more complex pattern.

This is the core reason why dynamic QR codes are visually superior to static ones for business use: a SMLLR dynamic code only encodes a 15-25 character redirect URL (e.g., smllr.app/a1b2c3), producing a clean Version 2-4 code. A static code encoding a full URL with UTM parameters (https://www.yourbrand.com/campaigns/diwali-2026?utm_source=print&utm_medium=flyer&utm_campaign=...) may produce a Version 10-15 code with a much denser, more complex pattern — harder to scan from a distance, harder to customize attractively, and impossible to update.

Smaller version = fewer modules = faster scan = better user experience = more scans.

The encoding process transforms your URL or text into the binary module pattern you see in the code. It passes through four stages:

Stage 1: Encoding Mode Selection
The encoder chooses the most efficient encoding mode for your data:
- Numeric mode: Digits 0-9 only. 3.3 bits per character. For phone numbers and postal codes.
- Alphanumeric mode: Uppercase A-Z, digits 0-9, and 9 specific symbols (space, $, %, *, +, -, ., /, :). 5.5 bits per character.
- Byte mode: Any character in ISO 8859-1, including lowercase letters, slashes, and all standard URL characters. 8 bits per character. Most URLs use Byte mode.
- Kanji mode: Japanese/Chinese double-byte characters. 13 bits per character.

Most marketing QR codes encode URLs in Byte mode.

Stage 2: Data Encoding
The encoder converts each character to its binary representation per the mode's encoding table, then concatenates the bits with a mode indicator prefix and a character count field. The result is a stream of binary data.

Stage 3: Error Correction Code Generation
The QR standard uses Reed-Solomon error-correcting code — the same algorithm used in CDs, DVDs, and deep-space communication systems. The encoder generates additional redundant codewords that allow the decoder to reconstruct the original data even if modules are damaged, obscured, or unreadable.

Stage 4: Module Placement and Masking
The binary data and error correction codewords are placed into the QR code grid in a specific zigzag pattern starting from the bottom-right corner, flowing upward and leftward. To prevent large solid-color regions (which confuse scanners), one of 8 defined masking patterns is applied — alternating the color of modules according to a mathematical formula. The encoder tests all 8 masks and selects the one producing the most balanced black/white distribution. The chosen mask number is recorded in the Format Information strips.

Error correction is the most underappreciated feature of QR codes — and the most important for anyone who designs branded QR codes or prints them on physical materials.

The QR standard defines four error correction levels:

Level L (Low): Recovers up to 7% data loss. Best for clean digital environments — QR codes displayed on screens where no physical damage is possible.

Level M (Medium): Recovers up to 15% data loss. Good general-purpose level for most marketing applications with light print wear.

Level Q (Quartile): Recovers up to 25% data loss. Ideal for outdoor print applications where the code may get wet, worn, or partially obscured.

Level H (High): Recovers up to 30% data loss. Required for branded QR codes with a logo in the center. If your logo covers 20-25% of the code's central area, Level H ensures the scanner can reconstruct that data from the redundant codewords. SMLLR defaults to Level Q for most codes and Level H when logos are added.

The trade-off: higher error correction = more redundant data = more modules needed = slightly larger or denser code. But the scanning reliability improvement is worth it for any print application.

Why do many 'designer' QR codes from other platforms fail to scan? Because they add logos at Level M (15% tolerance) when the logo actually covers 25-30% of the center area — exceeding the tolerance. SMLLR's Visual Studio shows you a real-time Scannability Score as you design, preventing you from creating an unscannable code regardless of how aggressively you customize it.

Here is the exact sequence of events from the moment you point your phone at a QR code to the moment the webpage begins loading:

0-10ms — Image Capture: Your smartphone camera captures multiple frames per second. The phone's OS continuously sends frames to a QR decoding library (Apple uses AVFoundation's QR detector on iOS; Google uses ML Kit or ZXing on Android) for continuous analysis.

10-30ms — Finder Pattern Detection: The decoder scans each frame looking for the 1:1:3:1:1 dark-light pattern that identifies a finder pattern. It must find all three finder patterns to confirm a valid QR code. Once found, it calculates the code's orientation and perspective correction matrix.

30-50ms — Grid Sampling: Using the three finder patterns and the timing patterns, the decoder establishes the coordinate grid. It samples each module at its calculated center point, comparing the brightness to a locally adaptive threshold to classify each module as black (1) or white (0).

50-80ms — Unmasking and Decoding: The decoder reads the Format Information strips to determine the error correction level and mask pattern. It applies the inverse mask to reveal the true data values, then extracts the data codewords in their zigzag reading order.

80-100ms — Error Correction and Final Decode: The data codewords are fed through the Reed-Solomon decoder. Any errors (up to the tolerance of the chosen level) are detected and corrected. The decoder then reads the mode indicator and character count, decodes the data payload according to the encoding mode, and produces the final string.

100ms — OS Notification: The phone OS receives the decoded string (e.g., https://smllr.app/a1b2). If it's a URL, it displays a notification banner or automatically opens the browser.

100-300ms — Dynamic Redirect (for SMLLR QR codes): If the decoded URL is a SMLLR smart link, the browser sends an HTTP GET request to SMLLR's nearest edge server. The server looks up the destination, evaluates routing rules, logs the scan event, and returns an HTTP 302 redirect. The browser follows the redirect to the final destination page. Total round-trip for Indian users: typically under 150ms.

From the outside, a static and a dynamic QR code look identical. The critical difference is in what is encoded — and what happens at scan time.

Static QR Code Architecture:
The final destination URL is encoded directly in the modules. When scanned, the phone decodes the URL and opens it immediately — no server involved.

Pros: Works without a redirect service. Cons: Cannot be changed. Cannot be tracked. Long URLs produce complex, harder-to-scan patterns. If the URL breaks, the code is dead permanently.

Dynamic QR Code Architecture (SMLLR):
A short SMLLR redirect URL (e.g., smllr.app/a1b2c3) is encoded in the modules — always just 15-25 characters regardless of your actual destination URL length. When scanned:
1. Phone decodes the short URL (instant, in 100ms)
2. HTTP request goes to SMLLR's edge server
3. Server looks up current destination for this QR ID
4. Server evaluates routing rules (device OS, geo-location, time of day)
5. Server logs scan analytics (city, device, browser, timestamp)
6. Server returns HTTP 302 redirect to final destination
7. Browser opens final destination

Total additional time for steps 2-7: 50-150ms for Indian users (thanks to NIXI-peered edge nodes). The user experiences seamless navigation. You gain full control and analytics.

SMLLR's routing engine can apply complex logic in this redirect step: send iOS users to the App Store and Android users to Google Play; show the morning menu before noon and the evening menu after 6 PM; display a Hindi landing page to users in UP and a Tamil landing page to users in Tamil Nadu — all from a single printed QR code.

When you create a dynamic QR code on SMLLR, you are provisioning a piece of globally distributed infrastructure, not just generating an image. Here is what runs behind every scan:

Edge Network: SMLLR's redirect infrastructure is peered directly at NIXI (National Internet Exchange of India) nodes in Mumbai, Delhi, and Bangalore. This ensures that Indian users' scan requests never traverse international routes unnecessarily, delivering redirect speeds of 30-80ms for most major Indian cities — including tier-2 markets like Pune, Ahmedabad, Jaipur, Chandigarh, and Kochi.

Rule Engine: Each QR code in SMLLR carries a configurable routing ruleset. In sub-millisecond processing time, the engine evaluates:
- Device OS and browser (for app deep-linking decisions)
- Country and city (via high-precision IP geolocation, accurate to city level)
- Time of day and day of week (for scheduled redirect rotation)
- Scan count (for limiting scans or triggering 'sold out' redirects)

Privacy-Safe Analytics Capture: Every scan event is logged with city, device category, OS, browser, and timestamp — but no Personally Identifiable Information (PII) is stored. No cookies are set. No user fingerprinting occurs. This design is DPDP Act (Digital Personal Data Protection Act, India) compliant from the ground up: you get the business intelligence you need without the regulatory exposure you don't want.

Anti-Quishing Protection: Every destination URL associated with a SMLLR QR code is checked against real-time malicious URL databases. If a URL is flagged as a phishing or malware domain, SMLLR blocks the redirect and notifies the account holder. This protects your customers and your brand reputation from being exploited through your own QR codes.

99.99% Uptime Architecture: A QR code printed on packaging, a billboard, or a business card is a permanent physical artifact. If your redirect service experiences downtime, every scan from every piece of print material in the field returns an error. SMLLR's infrastructure is designed with physical-world permanence in mind — multi-region failover, automated health checks, and redundant routing paths.

Understanding the technical reasons QR codes fail illuminates the engineering behind the technology:

Failure: Code too small for the scanning distance
A QR code needs a minimum size of approximately 2cm × 2cm for close-range scanning (held in the hand). For outdoor signage, use this formula: recommended QR size (in cm) = scanning distance (in meters) × 10. A bus shelter billboard viewed from 3 metres needs a QR of at least 30cm × 30cm.

Failure: Insufficient contrast
QR codes require a minimum contrast ratio of approximately 4:1 between modules and background. Black modules on white work perfectly. Dark navy on dark grey will fail. SMLLR's design tool warns you when the selected color combination falls below the safe contrast threshold.

Failure: Too much data encoded (high version, dense pattern)
This is the silent killer of static marketing QR codes. A long URL with UTM parameters may force a Version 12-15 code (61×61 to 77×77 modules) — a very dense pattern that budget Android cameras (extremely common in India's ₹8,000-15,000 segment) struggle with at normal distances. Solution: always use dynamic QR codes. SMLLR codes encode only 15-25 characters, typically producing Version 2-4 codes that scan reliably on any camera.

Failure: Quiet zone violation
If design elements (brand graphics, borders, text) extend into the 4-module quiet zone around the code, many scanners fail to detect the code boundaries. SMLLR's Visual Studio enforces the quiet zone automatically.

Failure: Damaged or dirty code
Outdoor print materials suffer weathering. Use Level H error correction (SMLLR default for outdoor-intended codes) to tolerate up to 30% module damage.

Failure: In-app browser WebView
Instagram, Facebook, Snapchat, and many Indian apps open links in their own in-app browser, which may have restricted camera API access. The user needs to tap 'Open in Safari' or 'Open in Chrome' to use the native QR scanner. SMLLR's redirect layer handles these environments gracefully, providing fallback URL handling for major in-app browser contexts.

The QR code's role in 2027 and beyond will be as the physical entry point for experiences that don't yet exist at scale:

AI-Powered Scan Destinations: Scanning a QR code will launch a zero-install AI agent (large language model) embedded in the browser — not just a static webpage. Scan a product and get instant answers to your questions in your language, recommendations based on your location, or a virtual customer service interaction.

WebXR via QR: Browser-based Augmented Reality (AR) is reaching mainstream quality in 2026. QR codes will launch WebXR experiences — try furniture in your room, visualize a renovation, 'wear' jewellery, or explore a property — all without app download. SMLLR's dynamic link layer will carry these heavy WebXR payloads to the right device with the right capability.

Voice-First Scans for Bharat: India's tier-2 and tier-3 markets have hundreds of millions of users who interact with technology primarily through voice. Future SMLLR QR scan destinations will detect language preference and offer voice-interactive experiences in Hindi, Marathi, Bengali, Gujarati, Tamil, and Telugu — removing the text-literacy barrier from QR code engagement.

ONDC and UPI Integration: As India's Open Network for Digital Commerce scales, every local merchant's QR code will double as an ONDC discovery endpoint — letting any consumer on any ONDC buyer app find and purchase from any physical store by scanning the code on the shopfront.

NFC + QR Hybrid Touchpoints: Premium products and events are combining NFC (tap to scan) with QR (camera to scan) on the same label, using SMLLR's unified smart link to serve the correct experience based on which technology triggered the interaction.

Each of these developments depends on the same foundation: a reliable, intelligent, updatable redirect layer behind a physical QR code. That foundation is what SMLLR provides today. Every code you create on SMLLR is a permanent physical asset connected to an infinitely adaptable digital experience — ready for whatever the next wave of technology brings.