How QR codes work

How QR codes work is a camera problem first and a hosting problem second. The phone finds three nested squares, samples a grid that starts at 21×21 modules, corrects damage, then reads bytes. If those bytes are a SmartQRCode URL, a second hop opens the live destination. If they are the destination, the job is already done.

How QR codes work once the viewfinder sees finder nested squares

The three finder patterns are how a camera locates the code. They are nested squares in three corners, specified by ISO/IEC 18004. Rotation, perspective, and a hand that is not square-on are solved because those finders have a known ratio. Covering, cropping, or over-logoing a finder is the most common reason a mark that looks fine will not scan. The fourth corner holds other timing and alignment structure; anatomy of a QR code names those pieces. The working rule is: leave the three finders visible and dark-on-light unless you have tested a true invert.

Quiet zone is a run of empty modules on all four sides, spec-minimum four. Type, foil, round corners, and trim that kiss the pattern steal that run. The camera then treats neighbouring ink as part of the grid. How QR codes work in a classroom or a shop is therefore also a layout problem: the viewfinder needs a light gutter, not a clever bleed.

iOS Camera and Android Google Lens or Camera both read QR from the viewfinder on current versions. There is no separate app requirement for a well-formed symbol. Some Android skins still bury the reader behind a mode toggle. A guest who cannot scan may have a camera that does not auto-detect. That is an OS issue, not a broken encoder.

How QR codes work in a dim hallway is still finders plus module size plus contrast. Low light fails more often than the wrong generator. Motion blur from a moving pavement is a distance problem. A second code in the same frame can steal the read. Test in the real room with the real phones. A studio desk is a different camera problem.

If you add a logo, you spend error-correction budget in the payload region. You do not add a fourth finder. Covering a nested square is still the usual fail. How QR codes work does not include a brand exception for crests. Leave the corners. Leave four modules of light. Then worry about hosted versus static, which is a hop after decode, not a different anatomy. How QR codes work on a glossy table under a downlighter is contrast plus size. Matte the symbol area. Enlarge if the phone is further than a desk. The spec will not name your millimetres. The room will. How QR codes work at a window is also backing the symbol with white so the street is not the light modules. Glass without a white patch is a contrast fail dressed as a design choice. How QR codes work on a bus window is that patch, plus size for pavement distance, plus a proof scan from the pavement. A studio desk will lie. How QR codes work from a moving pavement is size first, then light, then the hop if any. Do not blame the generator until the millimetres match the distance. How QR codes work after that is decode, then dispatch, then maybe a hop. Test all three. A pretty invert that mixes finder polarity with payload polarity will fail the first step. How QR codes work has no brand exception for that mix. Test the invert on the phone you expect guests to use. Then print.

Module version growth from 21×21 to 177×177

Version 1 is 21×21 modules. Each version adds four modules per side, up to version 40 at 177×177. The spec does not define a millimetre size. Scan distance is a function of module size and camera resolution, not of QR as a category. A version-1 mark at 4 cm is easy. A version-20 mark at 2 cm is pepper. More payload raises version, which raises density at a given print size.

That is why a short hosted address and a long static URL with UTM query strings do not look the same on a business card. The hosted pattern encodes the short URL. The static pattern encodes every campaign parameter. How to make a QR code turns this into a making choice. This page is the mechanism: version growth is the spec's answer to longer bytes.

If you need the print small, shorten what the modules store. Hosted types exist for that reason as well as for editability. How QR codes work at card size is therefore a payload-length problem before it is a colour problem. A long static campaign URL on a 2 cm card is pepper. A short hosted address on the same card is coarser squares. That is version growth, not a broken printer.

Byte mode in practice, plus numeric, alphanumeric, and kanji

Four encoding modes exist: numeric, alphanumeric, byte, and kanji. URLs and Wi-Fi payloads are byte mode in practice. Numeric packs digits. Alphanumeric is a restricted alphabet. Kanji exists for that set. A consumer generator picks a type; the library writes the mode. You feel the mode as density and as failure when someone pastes a character the chosen mode cannot represent.

A Wi-Fi payload commonly follows a MECARD-like WIFI:T: convention. SSID is case-sensitive. That string is still bytes in the modules. It is not a redirect. SmartQRCode's wifi type is static: the phone joins a network, no server hop, no scan totals. A website type is the opposite class: bytes that spell a hosted URL, then a 302.

How QR codes work for a teacher printing a form link is byte mode plus whatever happens after decode. How they work for a cafe printing the password is byte mode and then the Wi-Fi stack. Do not describe one class with the other's properties.

Why a longer payload looks busier at the same millimetres

Density is version plus error correction plus payload. Higher correction (Q or H) survives more damage and packs the same payload into a denser pattern. A logo in the centre is recovered by that correction, not by a special logo mode. If the logo covers more than the level can restore, finders may still be visible and the code still fails.

Error correction lists L, M, Q, and H as about 7, 15, 25, and 30 percent. The mechanism is restoration of modules the camera could not sample cleanly: scuffs, glare, a thumb. Making the pattern prettier by dropping to L on uncoated stock that drinks ink is how wipe-down tents fail. Compensate with a slightly larger symbol or a coated stock, not by starving correction. If the busy look is from a long static URL, shorten or host before you blame H.

What happens after the camera decodes bytes

The symbol is not a browser. After decode, the phone dispatches. An http URL opens a browser. A vCard payload is parsed by the contacts app; the user still confirms saving. A geo or maps URL opens whatever maps app the phone has set; there is no guarantee of Google Maps on iOS. A WIFI: string hits the wireless stack. A hosted SmartQRCode URL hits the tracker first.

Redirect types hop through the tracker with a 302 so later edits still land. A 301 would cache the first destination in some browsers and apps. Landing-page types serve a page you can rewrite. Scan totals, when they exist, are counts of those hops: time, device type, country from headers. They cannot see a name or email. A static file never hops, so there is nothing to count.

Static versus dynamic is the product vocabulary for that split. Mechanism: either the bytes were the destination, or the bytes were an address of a destination.

Quiet zone, invert, and renormalise inverted symbols

Light modules on a dark ground are legal only when finders remain dark-on-light as the camera expects, or when the whole symbol is a true invert the reader can renormalise. A dark ground with a dark pattern and no invert is unread. Metallic and foil grounds scatter; print the symbol on a solid white patch. Transparent stickers on glass pick up the street as the light modules; back the symbol with white.

Multiple codes in one camera frame: the reader typically returns one, not an average. Two tent cards in view can make it scans the wrong one look like a broken code. How QR codes work in a crowded table is a one-symbol-per-frame problem as much as a finder problem.

Low light and motion blur fail more often than wrong app. A handheld scan of a poster from a moving pavement is a size-and-distance problem first.

Hosted short URLs add a hop the spec does not require

The spec is satisfied when the modules decode. Hosting is a product choice. A hosted symbol lasts as long as that provider resolves the URL. A provider shutdown, an unpaid invoice, or a pause can stop a physically perfect print. A static code has no such dependency and no such editability. What a dynamic QR code is is the short vocabulary. This paragraph is the mechanism: DNS and HTTP after decode.

SmartQRCode is the host when you generate a hosted type. Canva's built-in QR is usually not a host; it writes the payload into the modules. Both can be valid ISO symbols. They are not the same system. Scan totals exist only when a hop happened. Country is a header, not a GPS chip in the ink. The camera finished its job before any of that. If the hop fails, the modules can still be perfect. Check DNS, pause state, and the destination, in that order, before you redraw the square. How QR codes work splits there: decode versus HTTP.

When a static generator explains the whole mechanism

If you want to see how QR codes work without a server, encode a short URL in Canva's widget or another free static generator and scan it. The phone opens the URL. That is the whole path. Use that path when the print will never change and will never be counted. Use a hosted type when you need the second hop: retarget, totals, a landing page you can rewrite.

Classroom handouts often want the second hop because assignment URLs churn. A birthday poster does not. How QR codes work does not change. The hop is optional. The finders are not. Paying for a hosted hop on a poster you will bin on Monday is wasted cost. Encoding a living shop URL as static Canva bytes is wasted reprint. Pick the path that matches the lifetime of the paper. How QR codes work is the same either way until the hop. After the hop, only hosted types can retarget. That is the only reason to pay for the hop on a classroom sheet.

Masks, timing lanes, and why a pretty invert still fails

The spec applies a mask so the payload is not a giant blank rectangle the camera could confuse with quiet zone. You rarely pick the mask in a consumer generator. You feel it as the pepper pattern. Timing lanes help the camera count modules when the paper is not square-on. Crop those lanes and version decoding slips. Anatomy names the parts; this section is why they exist in the sequence: finders first, then timing, then payload sampling, then error correction, then bytes, then dispatch.

A pretty invert that leaves finders as light-on-dark while the payload is dark-on-light is two rules at once. The camera expects one rule. Test the actual invert on the actual phone. Do not trust a desktop webcam.

Gloss coated stock reflects a downlighter into the camera. A code that scans on a desk fails on a table. Matte laminate on the symbol area is the usual fix. That is not a generator setting. It is how QR codes work under light.

Distance, millimetres, and why the spec will not give you a poster size

The spec does not define millimetres. A 2 cm working rule is for a phone at about 30 cm. Window decals, vehicle wraps, and lecture-hall slides are different distances. Module size at the eye, not panel width, sets the brief. A 2 cm code on a 6 m board is invisible from the road. How QR codes work at a trade stand is aisle distance of two to four metres, chest-to-head height, not a footer.

Apparel stretches. Sewn patches interrupt modules. Wash abrades ink. Those jobs need a larger symbol than paper at the same reading distance. The camera is unchanged. The substrate is not. Billboard size is set by the closest a scanner will stand, not by the panel width. Field cards collect dirt; H plus laminate plus size above 2 cm is the usual bundle. Healthcare waiting rooms are sitting distance, high contrast, matte, no clever invert. How QR codes work does not change by industry. The millimetres do.

Wi-Fi decode is a stack, not a browser

After bytes, a WIFI: string hits the wireless stack. A phone already on that SSID will appear to succeed even when the password is wrong, because nothing has to join. Confirm with a device that is not on the network. Hidden SSIDs and some enterprise EAP networks are poorly supported in the convention; do not promise them. How QR codes work for Wi-Fi is static payload plus OS behaviour. There is no dashboard hop to count those joins. Treat the printed password like a whiteboard password: anyone who can scan it has it. Reprint when the passphrase rotates. A Wi-Fi generator will not grow analytics if you add a logo. A cafe that reprints the password weekly should not also expect a scan graph from that mark. Put the menu URL on a hosted type beside it if you need totals. How QR codes work on that tent is two encodings, two rules.

vCard, maps, and other payloads the browser never sees

A vCard payload is parsed by the contacts app. The user still confirms saving. That is OS behaviour, not a landing-page toggle. geo: and maps URLs open whatever maps app the phone has set. Multiple codes in one frame return one result. How QR codes work after decode is dispatch, and dispatch is messy. Test the actual payload on iOS and Android. A Canva static vCard file is still a vCard; hosting is optional unless you will change the contact details after print. If you will change hours or a number, use a business landing or a hosted page instead of baking a stale vCard into modules. Test the save-contact sheet on iOS and Android; the UI differs and neither is a browser. How QR codes work for a vCard is decode, then a confirmation the user can cancel. Analytics will not tell you who cancelled.