QR Code Location Tracking: How to See Where Your Codes Are Being Scanned
Key Takeaways
Most QR “location tracking” is approximate location based on IP, usually city, region, and country.
If you want GPS-level coordinates, you need a landing page that asks for location permission. That extra step reduces completions, so use it only when it is truly worth it.
For campaign decisions, city-level plus device and time is usually enough to answer “which placements are working?”
Let’s kill the fantasy early.
A QR code does not magically know where someone is standing.
It opens a URL. That URL gets requested by a device. Your tracking system sees that request and makes a best-effort guess about location.
That is still incredibly useful. You just have to set expectations correctly.
This guide uses primary sources on location behavior: W3C Geolocation (permissions, accuracy semantics, and limitations), Android and Apple docs (approximate vs. precise controls), and Google Analytics Help (how geo is derived from IP).
What “QR code location tracking” really means (quick answer)
You can usually see the scan location at the country, region, and city levels.
That is typically derived from an IP address, not GPS. Google Analytics, for example, notes that it provides coarse geo-location data by deriving metadata from IP addresses, including city and the derived latitude and longitude of the city.
If you want something closer to GPS, you need to send scanners to a web page that requests device location. The W3C Geolocation spec calls this a powerful feature and says it requires express permission from the end user before any location data is shared with a web application.
How scan tracking works under the hood (the redirect chain)
Every QR scan is really a browser request.
A typical tracking flow looks like this:
Someone scans your code, and their phone opens a URL.
Your tracking system logs what it can from that request (timestamp, device, and sometimes approximate geo).
The system redirects the person to the final destination page.
This is why dynamic QR codes matter for analytics. You need a tracking layer in the middle.
If you want to connect location insights to conversions and revenue, pair this with GA4: how to connect QR codes to Google Analytics (GA4).
If you keep hearing people say “UTMs are enough,” this breakdown clarifies what UTMs do and what they don’t: UTM parameters vs QR code tracking.
If you already have city and region reports and want to interpret them correctly, use: QR code scan data by location: reading the numbers.
If your codes are on posters, menus, packaging, or signage, this print-first workflow pairs scan data with clean attribution: how to track QR codes on printed materials.
Where “location” comes from: IP geolocation vs device geolocation
There are two very different ideas people mix together when they say “location tracking.”
IP-derived location (passive and usually coarse)
IP-based location is passive. Nobody has to click “Allow.”
It is also imperfect. VPNs, corporate networks, and carrier routing can make people appear to be in a different city than where they actually are.
If you need a reminder of how loose this can be, MaxMind’s public comparisons show country-by-country variation and notes that geolocation is inherently probabilistic, not guaranteed.
Device geolocation (more precise, but permission-gated)
The W3C Geolocation spec lists common sources like GPS, IP address, Wi-Fi, Bluetooth MAC addresses, and cell IDs. It also explicitly states that no guarantee is given that the API will return the device’s actual location.
And it gets better. Even when a user allows it, “accuracy” is not a vibe. The W3C defines the accuracy value as 95% confidence at a meter level.
On Android, Google describes approximate location as accurate to within about 3 square kilometers, while precise location is usually within about 50 meters (sometimes a few meters). On iOS, Apple notes users can toggle “Precise Location” on or off for apps.
Option A: Use a QR platform’s built-in location analytics (most common)
This is the default choice when the goal is marketing decisions, not forensic tracking.
You get:
Country, region, and city trends
Device and OS breakdown (iPhone vs Android, browser types)
Time of day and day of week patterns
This is enough to answer the questions that actually move revenue:
Which locations are getting scans?
Which placements are dead?
Are scans happening at the time you expected?
If you also care about tying scans to on-site conversions, pair this with UTMs and GA4. More on that below.
Option B: Add a GPS permission step (HTML5 geolocation landing page)
If you truly need a more precise location, your flow becomes:
Scan
Landing page with a clear reason why you need a location
Permission prompt
Capture lat, long, accuracy radius, and timestamp
Redirect to the real destination
Be honest: this adds friction. Many users will deny permission.
The W3C spec is explicit that this requires express permission. So your best practice is to design for denial and timeouts. If they deny, log the scan, and fall back to IP-based approximate location.
Option C: Use GA4 for geo, device, and campaign reporting (UTMs)
GA4 is strong for answering: “Did scan traffic convert?”
It is not a QR scan counter. It is a website analytics system.
Still, it gives you location context. Google Analytics Help says it provides coarse geo-location data by deriving metadata from IP addresses, including city. It also notes that for EU-based traffic, IP address data is used solely for geo-location and then immediately discarded.
If you want to keep attribution clean, use UTMs consistently. If you want a plain-English breakdown of what QR code scan analytics actually measures, this is a good companion read: the QR code analytics guide.
Accuracy and expectations (so you don’t overpromise internally)
Here is the clean mental model:
IP geo is passive and useful for placement trends. It can be wrong.
Device geo can be more precise, but it requires permission and returns an accuracy radius rather than certainty.
If a vendor implies they can get “exact GPS from IP,” that is your cue to slow down and ask questions.
Also, do not forget the quiet privacy trap: location data is sensitive. Collect only what you actually need to make decisions.
Troubleshooting checklist (when your location data looks wrong)
All scans show one city
This is usually corporate routing, a shared network, or a carrier gateway. It does not mean the QR code is broken.
Lots of “unknown” locations
That can happen when IP geo resolution fails, privacy tools block requests, or your measurement setup is inconsistent. If you are relying on device location, denial is common.
Your GPS prompt never appears
Remember: geolocation requires permission, and it can be blocked at the OS level. In practice, it also needs a secure context (HTTPS).
FAQs
Can a QR code track someone’s exact GPS location?
Not by itself. A QR code opens a URL, and that URL can display an approximate location based on the user's IP address. If you want GPS-like coordinates, you need a permission-based landing page, and many users will decline.
Do users have to grant permission for GPS-level QR location tracking?
Yes. W3C notes that geolocation requires express permission before any location data is shared with a web application. If permission is denied, fall back to IP-based location or record the scan without coordinates.
How accurate is the location of the QR code scan at the city level?
It varies, and it can be wrong. Treat it as a campaign signal. It is great for comparing placements and regions. It is not a street address.
Why does my QR code location report show the wrong city (or one city for everyone)?
VPNs, corporate egress points, cellular carrier routing, and shared Wi-Fi can make many scans appear to come from the same city.
Can I see a scanner’s street address or indoor location from a QR scan?
Not reliably. IP-derived location is coarse. Device geolocation can be more precise, but it is permission-gated and still returns an accuracy radius rather than certainty.
Source list (quick references)
Pew Research Center mobile fact sheet (Nov 20, 2025): Mobile Fact Sheet
W3C Geolocation API specification: Geolocation API
Android Developers: Location permissions (updated Mar 30, 2026): Location permissions
Apple Support: Location Services and privacy (Jan 14, 2026): Control the location information you share
Google Analytics Help: EU-focused data and privacy: EU-focused data and privacy
Cloudflare docs: CF-IPCountry header: CF-IPCountry header
MaxMind GeoIP2 City accuracy comparison: GeoIP2 City accuracy comparison
Top comments (0)