QRCodeStack Community

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.

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

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.

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 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.