Geotargeted QR codes: how location-based redirects really work (and where they break)

Geotargeted QR codes: how location-based redirects really work (and where they break)

A geotargeted QR code promises something simple: one printed code, different destinations depending on where the person scanning it happens to be standing. A shopper in Rotterdam lands on the Dutch product page; the same code scanned in Berlin lands on the German one. For an agency running a pan-European print campaign, that is a genuinely useful trick. It is also one of the most oversold features in the QR code space, because almost nobody explains what "location" actually means at the moment of the scan, how accurate it really is, or when it quietly crosses into data you need consent to collect.

This guide covers the mechanics agencies actually need before they promise a client "smart" location targeting: the two entirely different technologies hiding under that one marketing term, the accuracy numbers for each (with sources), the GDPR line that separates "select a language" from "track a person", and the failure modes that show up on press day, not in the sales deck.

What "location-based" actually means: two different technologies

A QR code itself never stores GPS coordinates or knows where it will be scanned. It only encodes a short redirect URL. Everything that looks like "location intelligence" happens after the scan, on the server that URL points to, and it happens one of two ways.

IP-based geolocation is the default and by far the most common. The moment a phone opens the redirect link, the server sees the request's IP address and looks it up against a geolocation database to estimate a country, region and city. No permission prompt appears. The user does not know it happened. This is what powers "send this code's German scans to the German page" and it is genuinely reliable for that job, because country-level IP geolocation accuracy generally exceeds 99%, according to MaxMind, the company behind the GeoIP databases most redirect platforms use under the hood.

GPS-based geofencing is a different mechanism entirely. It requires the visitor's browser to ask for location permission (the prompt users are used to seeing from maps apps) and, if granted, reads the device's actual GPS or Wi-Fi-assisted coordinates. This is what would power something like "only show the in-store offer to people scanning within 150 metres of this specific shop", and it is precise enough to distinguish one building from the one next door, but only when the user grants permission, which most people scanning a poster in a hurry will not do.

The distinction matters because the two technologies have completely different accuracy profiles, completely different consent requirements, and completely different failure modes. A brief that says "make it location-based" without specifying which one is a brief an agency should push back on before scoping the work.

How accurate is IP-based geolocation, really?

This is the number every vendor blog skips, and it is the one that determines whether a geotargeting rule is worth building at all.

• Country level: accuracy generally exceeds 99%, per MaxMind's own published accuracy analysis. This is the one tier that is genuinely dependable for redirect logic.
• Region or state level: roughly 55-80% depending on the country, again per MaxMind. Good enough for broad marketing decisions, not for anything that needs to be right every time.
• City level: somewhere between 20% and 75%, an unusually wide range that depends heavily on the country and the type of network the visitor is on. This is an industry rule of thumb built from IP-database vendor accuracy testing rather than a single fixed spec, and it is the tier most "smart QR code" marketing pages quietly assume when they show a screenshot of "Paris" and "Lyon" landing pages.

Two things push city-level accuracy down further, and agencies should know both before they scope a city-specific rule:

Mobile carrier NAT. Mobile networks route huge numbers of subscribers through a small pool of shared IP addresses, and carriers reassign those addresses between users constantly. The practical effect, confirmed in MaxMind's own accuracy documentation, is that a mobile IP can resolve to a location tens or even hundreds of kilometres from the phone's actual position, and that resolution can shift within minutes as the carrier reallocates addresses. A print campaign in a mid-sized city with mostly mobile scanners should expect city-level misfires as a normal occurrence, not an edge case.

VPNs. A visitor on a VPN presents the IP address of the VPN's exit server, not their own. The geolocation lookup is accurate, it is just accurate about the wrong location. There is no way for the redirect server to detect this reliably at scan time, and corporate device policies, ad-blocking VPN apps, and privacy-conscious consumers all make this more common than it used to be.

The honest takeaway: build country-level or continent-level redirect rules with confidence. Build city-level or neighbourhood-level rules only with an explicit fallback for the (routine, not rare) cases where the location guess is wrong, and never scope a client deliverable that promises city-level accuracy as a guarantee.

How accurate is GPS-based geofencing?

Geofencing works differently, and its accuracy comes from Android and iOS location services rather than an IP database, so the numbers are tighter, but only once permission is granted.

Android's own geofencing documentation recommends a minimum geofence radius of 100 to 150 metres for reliable triggering, and gives a breakdown of why: with Wi-Fi available, location accuracy is roughly 20 to 50 metres; with indoor positioning available, it can tighten to around 5 metres; but without Wi-Fi, for example on a highway or in a rural area relying on cell towers and GPS alone, accuracy degrades to several hundred metres and can reach multiple kilometres. A geofence radius set tighter than the platform's own recommended minimum will trigger unreliably or not at all, which is the single most common reason a "welcome offer when you walk past our shop" QR/geofencing pairing quietly fails in production.

The consent requirement is the bigger practical barrier, though. Precise geolocation only works if the visitor's browser explicitly grants permission, and most people scanning a code on a poster, a menu, or a flyer are not going to tap "Allow" for a location prompt from a page they have never visited before. In practice, GPS-based geofencing is best suited to an app or a returning-visitor web experience where trust has already been established, not to a cold scan from print.

The GDPR line: when location data needs consent, and when it doesn't

This is the part competitor guides mention in passing and then skip, and it is the difference between a defensible campaign and a compliance problem.

An IP address counts as personal data under GDPR. This is explicit: GDPR's definition of personal data includes online identifiers, and regulatory guidance treats an IP address as personal data whenever it can be linked back to an individual, including indirectly, for example via logs an ISP could in principle disclose under legal process. That single fact governs everything that follows.

The line that actually matters in practice, per guidance on geolocation and consent under the ePrivacy framework, runs between coarse and precise use of that data:

• Using an IP address only to infer a country, for the purpose of picking a language or currency or routing to the right regional page, generally does not require separate consent. This is the standard, low-risk use case: "this scan came from Germany, show the German page."
• Using location data that is precise enough to identify an individual's device at a city, street, or building level, and using it for behavioural targeting (a specific offer, a retargeting pixel, a profile update) rather than simple content routing, does require consent under ePrivacy and GDPR. The trigger is not the technology, it is the precision and the purpose: the same IP lookup that is fine for "show the Dutch page" becomes a consent-requiring action the moment it is used to build or update a profile of that specific visitor.

GPS-based geofencing sits unambiguously on the consent side of that line by design, since the browser's own permission prompt is the consent mechanism. The grey area agencies should watch is IP-based targeting that starts as "just pick a language" and quietly expands into "also log this visitor's inferred city against their scan history for retargeting", without anyone updating the privacy notice or consent flow to match. For the broader picture of what a tracked scan collects and what a privacy notice needs to say, see are QR codes GDPR-compliant.

What a geotargeted redirect can plausibly deliver today

Put the mechanics and the accuracy numbers together and a clear brief emerges for what to promise a client, and what not to.

Reliable and worth building:

• Country-level content or language routing from a single printed code (a pan-European flyer, a product with regional pricing, an event with international attendees).
• Device-based routing alongside location (sending iOS scanners to the App Store and Android scanners to Google Play from the same code), which uses the browser's user-agent rather than location data at all; see one QR code, two app stores for that mechanism specifically.
• Regional campaigns where "close enough" is genuinely close enough, such as routing by country or by a handful of major metro regions rather than by neighbourhood.

Fragile, and should come with an explicit caveat before a client signs off:

• City-level or postcode-level redirect rules, given the 20-75% accuracy range and the mobile carrier NAT effect.
• Anything relying on a scanner being on a specific Wi-Fi network or within a tight geofence from a cold, first-time scan of a printed code, since that requires a permission prompt most people will decline.
• Any promise that the rule will be "always accurate", which no vendor's own documentation supports at anything finer than country level.

Not what a QR code does on its own:

• The QR code is never the thing doing the location detection. It is a static pointer to a redirect service; every geotargeting decision documented here happens on the server after the scan, which is also why a code's destination can change without reprinting, and why the underlying scan-location data (country, city, device type) that any of this depends on is exactly the kind of thing worth tracking properly regardless of whether a location-based rule is in play. See QR code analytics: which scan metrics matter for what that data looks like once it is being collected.

The two lanes above are what "location-based" collapses into in practice: an automatic, coarse, no-permission lookup that is reliable at country level and shaky below it, and a precise, permission-gated lookup that is tight but only fires when someone explicitly agrees to share their location. Most "smart QR code" marketing describes the second and quietly delivers the first.

A practical checklist before promising a client "location-based" targeting

1. Ask which technology the brief actually needs. "Different language per country" is an IP-based job. "Different offer within 200 metres of this specific store" is a GPS-based job requiring an opt-in experience, not a cold print scan.
2. Set expectations at the right precision. Commit to country-level accuracy in writing if that is what the mechanism supports; do not let "city-level personalisation" survive into a client deck if the underlying technology cannot reliably deliver it.
3. Build a sensible fallback. Every geotargeting rule needs a default destination for the routine cases where the location guess is wrong, ambiguous, or (for GPS) never granted permission in the first place.
4. Separate "content routing" from "profiling" in the privacy notice. If the rule only ever picks a language or region, say so plainly. If any part of the campaign logs inferred location against a specific visitor's scan history for retargeting or reporting on individuals, treat that as requiring consent and update the notice and consent flow accordingly.
5. Test from a mobile network, not just office Wi-Fi. Mobile carrier NAT is the most common cause of a geotargeting rule that worked perfectly in every internal test and then misfires repeatedly once the campaign goes live on the street.

Frequently asked questions

#### Can a QR code know my location?

Not by itself. The QR code only encodes a redirect link. Once a phone opens that link, the server behind it can estimate location one of two ways: automatically from the request's IP address (coarse, no permission needed, reliable at country level), or, if the browser explicitly requests and receives permission, from the device's GPS (precise, but requires an opt-in the user must actively grant).

#### Does a QR code need GPS or location permission to work?

No, not for country-level or region-level targeting, which uses the IP address automatically and needs no permission prompt. GPS-based precision, the kind needed for a tight geofence around a single building, does require the browser to ask for and receive explicit location permission, which most people scanning a printed code for the first time will not grant.

#### What's the difference between a smart QR code and a dynamic QR code?

A dynamic QR code points to a redirect that can be edited later, so the destination can change without reprinting the code. A "smart" or conditional QR code is a dynamic code whose redirect server additionally applies rules, based on location, device, language or time, to send different scanners to different destinations from the same printed code.

#### What's the difference between geotargeting and geofencing?

Geotargeting typically refers to broad, IP-based location inference (country or region) used to route content. Geofencing specifically means a defined geographic boundary, usually GPS-based, that triggers an action when a device enters or exits it. Geotargeting is the coarse, automatic version; geofencing is the precise, permission-gated version.

#### How accurate is IP-based geolocation for a QR code scan?

Country-level accuracy generally exceeds 99%. Region or state-level accuracy runs roughly 55-80% depending on the country. City-level accuracy ranges widely, from about 20% to 75%, and is further reduced on mobile networks due to how carriers share and reassign IP addresses among subscribers, and defeated entirely by VPN use, according to accuracy analysis published by MaxMind, whose GeoIP databases underpin most geolocation lookups.

#### What's the minimum geofence radius that actually works?

Android's own geofencing guidance recommends a minimum radius of 100 to 150 metres for reliable triggering. Anything tighter risks failing to trigger consistently, since real-world location accuracy without Wi-Fi assistance can be several hundred metres to a few kilometres, and even with Wi-Fi available typically only tightens to roughly 20 to 50 metres.

#### Can a VPN fool a QR code's location tracking?

Yes. A VPN presents the IP address of its exit server rather than the user's actual location, and the geolocation lookup will confidently, and incorrectly, report the exit server's location. There is no reliable way to detect this at scan time, so any IP-based rule should assume a small but real share of scans will be geolocated wrong for this reason.

#### Do location-based QR codes require GDPR consent?

It depends on precision and purpose. Using an IP address only to infer a country for language or currency selection generally does not require separate consent. Using location data precise enough to identify an individual's device, or using it to build a profile or target advertising to that specific visitor, does require consent under GDPR and the ePrivacy rules, because an IP address is legally personal data the moment it can be linked back to a person.

#### Is an IP address personal data under GDPR?

Yes. GDPR's definition of personal data explicitly includes online identifiers, and regulatory guidance treats an IP address as personal data whenever it could reasonably be used, including indirectly through an internet provider's logs, to identify a specific individual.

#### How do agencies run one QR code across multiple locations or franchises?

The same dynamic-code mechanism that enables geotargeting supports this without location detection at all: many agencies simply generate a distinct code per store or per employee, each pointing to its own tracked landing page, so every location gets clean, unambiguous reporting rather than relying on a single shared code to guess which store a scan belongs to. See one workspace per client for how that structure is typically organised.

#### Why did my location-based QR code send someone to the wrong country's page?

Almost always one of two causes: the scanner was on a VPN, which reports the exit server's country rather than their own, or the scanner was on a mobile network, where carrier IP reassignment can resolve to a neighbouring country or region, particularly near a border. Both are routine, expected behaviour for IP-based geolocation, not a bug in the redirect rule.

The short version

A geotargeted QR code is really two different technologies wearing one marketing label. IP-based geolocation is automatic, needs no permission, and is genuinely reliable at country level (99%+ accuracy) but shaky at city level (20-75%, worse on mobile networks, defeated by VPNs). GPS-based geofencing is precise, but only fires when a visitor explicitly grants location permission, which a cold scan from print rarely gets. The GDPR line sits between using location to pick a language (usually fine without extra consent) and using it to profile or target an individual (needs consent). Before scoping a location-based rule for a client, confirm which of the two technologies the brief actually needs, commit to country-level accuracy rather than city-level promises, and build a fallback destination for the routine cases where the location guess is wrong.