Geo-Based QR Routing: How One Code Sends Each Scan Where It Belongs
Geo-based QR routing means one printed QR code can send people to different pages depending on where they scan it. A scan in Texas can open a Texas offer, a scan in Ontario a Canadian page, and a scan outside your service area a general landing page. It works because the code points to a short redirect address, and a server decides the final destination at the moment of the scan. This guide explains how that decision is made, how accurate it is, where it goes wrong, and what US and UK regulators say about location data.
TL;DR
- Geo-based routing needs a dynamic QR code. A static code holds one fixed URL and cannot react to location.
- Most routing uses the scanner’s IP address, which is reliable at country and region level and less so at street level. GPS needs the scanner’s explicit permission.
- Always set a fallback destination for scans that cannot be placed, and test your rules from more than one location before printing.
- Location is sensitive data. Be open about what you collect, collect no more than you need, and stay away from sensitive places.
- Pick a platform whose codes keep working, because a routing rule is useless if the code behind it is switched off.
Table of Contents
- What geo-based QR routing actually is
- How the redirect works, step by step
- Two ways to find the scanner’s location
- When geo-based routing is worth it
- How to set up geo-based QR routing
- Reading the results
- Privacy: what the regulators say about location data
- Common mistakes
- Our perspective
- Start with a code that keeps working
- FAQ
- Sources
What geo-based QR routing actually is
A standard QR code stores a web address. Scan it, and the phone opens that address. Nothing about the scanner changes the result.
A geo-routed code works differently. The code stores a short redirect URL on the platform’s server. When the phone requests it, the server looks at the request, estimates where it came from, checks your rules, and sends the phone on to the matching page. The whole exchange takes a fraction of a second, and the scanner never sees the middle step.
That is why people also call it location-based redirecting or geo-targeted QR marketing. If you want the wider marketing picture, our guide to geo-targeted QR marketing covers what it is and when it pays off. This article focuses on the routing mechanics.
How the redirect works, step by step
- The scan. The camera reads the code and the phone opens the short redirect URL.
- The request. The phone’s browser sends a normal web request to the platform’s server. That request carries the device’s IP address, its browser and operating system, and its language setting.
- The location estimate. The server matches the IP address against a geolocation database and gets back a country, region and often a city.
- The rule check. The server compares that result with your rules, for example “US, state of California” or “anywhere in Canada”.
- The redirect. The server answers with the matching destination. If no rule matches, it sends the scanner to your fallback page.
- The log. The scan is recorded for analytics, which is what feeds scan maps and regional reports.
The key point is that steps 2 to 5 happen on the server. The scanner installs nothing and is not asked for anything. That is also why the method is simple to run and why its precision has limits.
Two ways to find the scanner’s location
The pages that rank for this topic mostly agree there are two methods, and the difference matters for both accuracy and privacy.
| IP-based | GPS or browser-based | |
|---|---|---|
| How it works | Server estimates location from the IP address | The phone reports its own coordinates |
| Scanner action needed | None | Must approve a permission prompt |
| Typical precision | Country and region are dependable, city is usually decent, street is not | Can be very precise |
| Friction | None, the redirect is instant | A prompt appears, and many people decline |
| Best for | Routing by country, state or metro area | Store-level or venue-level experiences |
| Privacy weight | Lower, but still location data | Higher, needs clear consent |
Browsers deliver GPS-style location through the Geolocation API, and the MDN documentation states that the user is asked for permission before location is reported. That prompt is the reason GPS routing rarely suits a QR code that should open a page instantly. Most teams use IP routing for the redirect itself and keep GPS for pages where the visitor actively asks for something like “find my nearest store”.
What IP-based routing gets wrong
IP geolocation is an estimate. Plan for these cases:
- Mobile carriers. Traffic can appear to come from a carrier gateway in another city or state.
- VPNs and privacy relays. A scanner using one will be placed where the exit point is, not where they stand. Google’s own IP Protection explainer describes how it shares the regions that its proxied addresses map to, which shows the industry is building privacy features that blur exact location on purpose.
- Border areas. Someone standing in one state can be placed in the neighbouring one.
- Rural areas. City-level accuracy tends to be weaker outside dense urban areas.
The practical rule: route by country or broad region when a wrong guess is costly, and use a city rule only when the fallback is nearly as good as the targeted page.
When geo-based routing is worth it
Routing adds a layer you have to maintain, so use it when location genuinely changes the right answer.
Multi-region campaigns. One printed pack or poster goes out nationally, but offers, prices, languages or legal terms differ by region. One code replaces a dozen versions that someone has to keep apart in the warehouse.
Franchises and multi-location retail. A single code on a national flyer can send scanners to the page for the nearest metro area. Each local manager owns their own page, and the print run stays the same.
Events and touring campaigns. A banner that travels from city to city can keep the same code while the destination changes with each stop. Our guide on updating QR code destinations explains the editing side.
Language and currency. Sending visitors in a Spanish-speaking region to a Spanish page, or showing prices in the right currency, removes a step where people give up.
Regional compliance. Some offers, such as promotions or age-restricted products, are only valid in certain states. Routing can keep a scanner from landing on an offer they cannot redeem. Check with your legal adviser on the exact rules for your product, because a routing rule is a convenience, not a legal safeguard.
For the marketing side, a case study on a QR-focused site’s organic growth shows how localised, intent-matched pages can pull in more of the traffic you then route. And our piece on personalised QR journeys and conversions explains why matching the page to the person lifts results.
How to set up geo-based QR routing
The steps are the same on any platform that supports rules.
- Decide what changes by location. Write the list: offer, language, price, store finder, legal text. If only one thing changes, a single page with a location-aware block may be simpler than several destinations.
- Build one page per destination. Each must work on a phone, load fast, and make sense on its own, because a scanner will never see the other versions.
- Create a dynamic QR code. It needs to be editable after printing. Our dynamic QR code generator produces codes whose destination you can change without reprinting.
- Write the rules in order of specificity. City before region, region before country, country before the default. Rules that overlap are the most common cause of a scan landing in the wrong place.
- Set a fallback. This is the page for unknown locations, VPN users and everyone outside your rules. Make it a useful general page, never an error.
- Test from several places. Use a mobile connection and Wi-Fi, and ask colleagues in other regions to scan the live code. A VPN is a quick way to simulate other countries.
- Print with care. Leave the quiet zone around the code intact so it scans reliably. Our note on the QR code quiet zone explains how much space it needs.
- Check the analytics weekly in the first month. Look for regions with unexpected volume, or a large share landing on the fallback.
Reading the results
Routing and analytics belong together. Each scan is already logged with a rough location, so the same data that drives your rules tells you whether they work. Useful checks:
- Fallback share. If a high share of scans lands on the default page, your rules are too narrow or your audience is somewhere you did not expect.
- Scans by region against distribution. If a city gets scans but you never printed there, something is travelling further than planned. That is a finding, not an error.
- Conversion by destination. Compare the action rate on each regional page. A weak page needs content work, not a new rule.
- Time patterns. Regional scans by hour show when local audiences are active.
You can see what this looks like in practice on our QR codes with analytics page, and our guide to link redirection for QR campaigns goes deeper on tracking through the redirect.
Privacy: what the regulators say about location data
Location data is among the most scrutinised kinds of personal information, even when it is only a city. If you route or track by location, treat privacy as part of the design.
In the US, the Federal Trade Commission has taken enforcement action over location data. Its business guidance on four recent cases shows the agency treats location information as sensitive, and its takeaways centre on how data is collected, shared and sold, particularly when it can reveal visits to sensitive places. If you operate in or market to the UK or EU, the GDPR family of rules applies on top of that.
From this, a few sensible habits follow:
- Collect only what you need. If routing by country does the job, do not store city-level history.
- Say what you collect. A short line in your privacy policy, and on the destination page where it fits, is a trust signal as much as a legal one.
- Give people a way out. Make it easy to ask for deletion or to withdraw consent where consent applies.
- Avoid sensitive locations. Do not build campaigns that single out visits to places such as medical facilities or places of worship.
- Take extra care with children. The UK regulator’s guidance on geolocation says location options should be off by default for children and that there should be an obvious sign when location is being tracked. If your audience includes minors, take that seriously.
This is general information, not legal advice. For your own campaigns, ask a privacy lawyer or your data protection officer to review what you collect and where it is stored. Our guides to QR data privacy and GDPR-compliant QR codes cover the practical side for marketers.
Common mistakes
- Using a static code. The location logic lives on the server, so the code must be dynamic. A static code cannot be rerouted afterwards.
- No fallback. The scans you lose are exactly the ones you did not plan for.
- Routing on a guess. If a wrong match sends someone to a page that does not apply to them, widen the rule.
- Forgetting the page itself. A perfect rule that ends on a slow or non-mobile page wastes the work.
- Letting the code die. Many free generators switch codes off when a subscription ends or a payment fails. Every rule and every printed copy goes with it.
Our perspective
We build QR tools, and the first thing we tell teams about routing is that the clever part is the least important part. The rules can be rewritten in minutes. The printed code cannot.
That is why we guarantee that codes created during an active subscription keep working permanently, even after cancellation or a billing problem. A regional campaign might run for years: the sticker on a delivery van, the label on a product, the poster in a train station. If the code behind it is deactivated, you lose the routing, the analytics and the printed material in one go.
On location, we favour the least data that does the job. Country and region rules cover most real campaigns, and they are easier to explain to your customers and your legal team. Add precision only when the page you route to truly improves because of it.
And test like a scanner, not like a marketer. Scan on mobile data, from a different place, with a VPN on and off. The version of your campaign that matters is the one a stranger sees.
— The
Start with a code that keeps working
If you want to try dynamic codes with scan analytics, you can create a free account without a credit card. The Free plan costs $0 per year and comes with limited codes and analytics, and the Pro plan unlocks unlimited codes, advanced analytics and API access. See the pricing page for the current plan details, or start with the free QR code generator.
FAQ
Do I need a dynamic QR code for geo-based routing?
Yes. A static QR code contains the final URL itself, so every scan goes to the same place. Routing needs a short redirect address that a server can answer differently depending on the request, and that is what a dynamic code provides.
How accurate is location from a QR code scan?
IP-based location is dependable at country and region level and often good at city level, but it is an estimate. Mobile carriers, VPNs and border areas can all place a scanner in the wrong spot, so build rules that still work when the guess is off, and always set a fallback page.
Does the scanner have to give permission?
Not for IP-based routing, which happens on the server during the redirect. GPS-style location is different: browsers ask the user before sharing it, as the MDN Geolocation API reference explains. For that reason, GPS suits pages where the visitor asks for a nearby result, not the first redirect.
Is tracking scan location legal?
It depends on what you collect, where your audience lives and how you use it. US regulators such as the FTC treat location data as sensitive, and the UK and EU have stricter rules still. Collect the minimum, be transparent, and have a privacy professional review your set-up.
Sources
- Geolocation API, MDN Web Docs
- 10. Geolocation, ICO Children’s code guidance
- IP Protection: IP geolocation explainer, GoogleChrome on GitHub