QRCodeStack Community

Most small brands asking this question do not need it yet. It is worth knowing how to tell whether you are the exception, because the answer changes what you print. What it is, briefly A GS1 Digital Link QR code carries structured product identity — the same identifiers a barcode carries — inside a web URL. One code can then serve a shopper a product page and a scanner at a till the identifier it needs. The industry direction of travel is that retail point-of-sale systems should be able to read 2D codes at checkout by 2027. Who needs to care now You sell through a major retailer that has told you to. This is the common real trigger. If a buyer has sent you a specification, follow the specification. You are in a regulated category — food with mandated allergen information, cosmetics, pharmaceuticals, or anything with a digital product passport obligation coming. You need one code to work at a till and on a phone, because you cannot afford the packaging space for two. Who does not, yet If you sell direct to consumers, at markets, through your own shop or your own website, and no retailer has handed you a requirement — a plain dynamic QR code pointing at your product page does everything you need today. It is cheaper, simpler, and you can change where it goes. The honest framing: adopting this early costs you real effort, and the benefit arrives when your retail partners' systems catch up. If nobody in your chain is asking, that benefit is deferred. If you do need it The identifiers must be correct and genuinely yours — this is the part that is not worth improvising. Get the product identifiers right first, then encode them. A well-formed code with the wrong identity is worse than no code, because it will be trusted. We support the current URI syntax and the resolver behaviour, so if you have a specification from a buyer you can implement against it. If you are not sure whether the specification applies to you, post it here with the identifying details removed and we will read it with you.

Scan counts are more slippery than they look. Worth knowing what is behind the number before you make a decision with it. What a scan can tell you That a redirect was served, with a timestamp Device, browser and operating system, from the request Roughly where from — see the tier note below Which code, so you can compare placements against each other What it cannot tell you Whether a human saw anything. A request is not a person. What happened next. Whether they read the menu, followed the account, or bought something happens beyond the redirect. Who they are. No identity comes attached to a scan, and any claim otherwise should worry you. The bot problem, and why the number you want is smaller Not every request is a person with a phone. Link previews from messaging apps fetch the destination to build a thumbnail. Security scanners follow links in email. Crawlers wander. Paste a code's link into a group chat and you can generate a dozen "scans" before a human sees it. We classify traffic rather than counting every request equally, and separate engaged scans from automated ones. It means our headline number is often lower than a raw request count — which is the point. A number that flatters you is not useful for deciding where to put the next sign. This matters most when comparing placements. A code shared in a chat group and a code on a shop window collect very different proportions of automated traffic, and comparing their raw totals will mislead you. Location, honestly Location comes from IP address, which is an approximation — it can be off by a city, and a VPN moves it entirely. Treat it as a regional signal, never as where someone physically stood. Depth of location detail depends on plan: the full city-level breakdown and scan map are on Advanced, and the free trial includes a taste of it. Starter and Pro show top countries rather than the full city map. A practical way to use the numbers Compare like with like, over the same period: same code, two placements. Absolute totals mean little; the difference between two placements of the same code is a real signal you can act on.

Most contact QR codes are static vCards: name, title, company, phone and email encoded straight into the pattern. They work offline, forever, with no account behind them — and they are frozen the moment they are printed. That is fine for a conference badge. It is a problem for a business card you ordered 500 of, if you change your title, your number, or your employer. The two approaches Static vCard. The contact details live in the code. Scanning it offers to save a contact immediately, with no internet connection. Nothing to maintain, nothing to pay for, nothing you can ever change. Dynamic. The code points at a short URL that serves your details. Scanning it opens a page that offers the same contact download. You can update your title or number afterwards and every printed card follows. It needs a working connection at scan time, and it depends on the link continuing to resolve. Which to choose Ask how long the card will be in circulation and how likely the details are to change. A card you reprint every year with a landline that never moves: static is simpler. A card you hand out for three years with a mobile number and a title that might change: dynamic pays for itself the first time you get promoted. What actually happens on the phone Saving a contact from a QR code is a two-step action on both major platforms — the phone shows the details, then the person confirms. There is no way to write to someone's address book silently, and you should be suspicious of anything claiming otherwise. Keep the payload small. A vCard with a long photo embedded produces a dense code that scans badly at business-card size, which is exactly the size constraint you cannot escape here. Put a name next to it "Scan to save my details" next to the code roughly doubles the number of people who do. A bare square on a card reads as decoration.

A WiFi QR code encodes the network name, the security type and the password, so a phone can join without anyone reading a password off a chalkboard. Worth getting the details right, because this is one of the few QR types where a mistake locks people out rather than sending them somewhere wrong. Use your guest network, not your main one Put the code on the guest SSID. Anything encoded in a QR code on a public table is, by definition, public — a photograph of it is a permanent copy of the password. On your main network that is a real problem; on an isolated guest network it is simply how it works. Most business routers can run a guest network that reaches the internet but not your till, your printer, or your back-office machines. If yours can, use it. The details that trip people up Security type must match. WPA2 and WPA3 are not interchangeable in the encoding. If the code is built for the wrong one, phones will try and fail with an unhelpful error. Hidden networks need to be marked as hidden. Otherwise the phone looks for a broadcasting network, finds nothing, and gives up. Special characters in the password. Semicolons, colons, backslashes and quotes have meaning inside the WiFi payload. A password containing them needs escaping. If you have a choice, pick a password without them — it removes a whole class of failure. Case matters, in both the network name and the password. Rotating the password The moment you change the password, every printed code becomes a support conversation. Two ways to live with that: Change it rarely, on a schedule you control, and reprint deliberately Point the code at a short URL that opens a page with the current details, which you can update without reprinting — slower for the guest by one tap, but it never goes stale Put it where someone sitting down can reach it Table tents and the back of the menu work. A sign behind the counter does not — people connect after they sit, not while they order.

The problem worth solving here is not "how do I make a QR code". It is that people walk past your shop, like what they see, and have no way to keep it. Typing a handle into a phone in the street is enough friction to lose most of them. What to point it at Your public profile URL — instagram.com/yourhandle. Not a post, not a story, not a link-in-bio page. Someone standing outside your door wants the account, not a specific photo from last Tuesday. Static or dynamic? Both work. The question is whether you will ever want to change where it goes. Static encodes the profile URL directly. It works forever, needs no account, and can never be changed. Dynamic points at a short URL that redirects. You can change the destination later — to a campaign page during a sale, then back — and you can see how many people actually scanned it. If the code is going on a window sticker that stays up for two years, dynamic is worth it for the one time you want to redirect it without reprinting. Where it actually gets scanned At eye level near the door, not at knee height on the glass On the counter, where people wait anyway On the receipt or the bag, which travels home with them Not on a moving vehicle, and not on the floor Say what it is A bare code gets ignored. "Follow us" plus the code beats the code alone, every time. People scan when they know what they are getting. One honest caveat Scan counts are not follower counts. A dynamic code will tell you how many people scanned and roughly where from — it cannot tell you who followed, because that happens inside an app we have no visibility into. Compare your scan numbers against your follower growth over the same period and treat the gap as the cost of the handoff.

A code that works on your monitor and fails on card is almost always one of these five. 1. Not enough contrast. Cameras read light and dark, not colour. Dark-on-light with a real difference in brightness works; mid-grey on beige does not, however good it looks in the mockup. If you are unsure, photograph the printed code in black and white — if you can barely see the pattern, neither can a phone. 2. Inverted colours. Light code on a dark background fails on a meaningful share of scanners. Some read it, some do not, and you will not know which your customers carry. 3. The quiet zone was trimmed. The clear margin around the code is part of the code. Layouts routinely eat it. 4. Gloss and lamination. A glossy laminate under a downlight throws a highlight straight back at the lens. Matte finish is worth the small extra cost anywhere the code sits under direct light. 5. Too much data crammed in. The more you encode, the more modules, the finer each one, the worse it survives ink spread. Pointing at a short URL instead of a long one with tracking parameters attached is the single easiest fix. Error correction is not a free pass Higher error correction lets a code survive damage — a logo in the middle, a scuff, a fold. It does this by adding redundancy, which means more modules in the same space. Turning it up to survive a logo can make a small code harder to scan, not easier. If you are placing a logo, grow the code at the same time. When it is already printed If a run is out in the world and scanning badly, a dynamic code is the difference between a reprint and an afternoon: the destination can be changed without touching the artwork. A static code cannot — the destination is baked into the pattern itself. That is the main reason to prefer dynamic for anything that gets printed in volume.

The short answer is a ratio, not a number: the code should be about one tenth of the distance it will be scanned from. Scanned from 30 cm (a table tent, a business card): 3 cm minimum Scanned from 1 m (a shop window, a counter sign): 10 cm Scanned from 3 m (a wall poster): 30 cm Scanned from 10 m (a banner, a vehicle): 1 m Treat those as floors, not targets. A code that is comfortably too big costs nothing; one that is 15% too small fails silently and you never hear about it. The three things that break a technically correct size The quiet zone. A QR code needs clear space around it — roughly four modules' worth, where a module is one of the little squares. Designers trim it constantly to fit a layout. A code with artwork crowding its edge fails at any size. Module size after printing. What matters physically is how big one module ends up. Below roughly 0.5 mm per module, ink spread on absorbent stock starts merging neighbouring modules. If your code encodes a lot of data it has more, smaller modules at the same overall size — which is one practical reason to point a code at a short URL rather than a long one. The surface. Curved bottles, textured card, anything laminated glossy under a shop light. Curvature distorts the grid; gloss throws back the light the camera needs. On a curved surface, go a size up and keep the code away from the steepest part of the curve. Test it the way a customer will Print one, at final size, on the final material. Then scan it: at the real distance, at an angle, in the actual lighting, on the oldest phone in the office. A code that works on your desk under a lamp tells you nothing about a rainy Tuesday outside a café. If you are printing a run of thousands, the ten minutes this takes is the cheapest insurance available.

Welcome — this is where QRCodeStack questions get answered in public. What belongs here How do I do X with a dynamic QR code, short link, or scan analytics? Something behaving unexpectedly, before it's worth an email Feature requests, and the reasoning behind them What you built, if you think others would find it useful What doesn't Account, billing, or anything with personal data — email support@qrcodestack.com instead. Posts here are public and indexed by search engines. Why public Most questions get asked more than once. Answering them where the next person can find them beats answering the same email twice. Product: qrcodestack.com · Pricing: qrcodestack.com/pricing