Location QR codes — single place vs directions, done right

A location QR code is the smallest, most useful piece of print real estate a venue ever owns — a square that turns the printed address on a sign, a postcard, or a welcome note into a one-scan trip to the front door. Done right, it opens Apple Maps on iPhones and Google Maps on Android with the same printed square. Done wrong, it dumps the scanner on a half-broken map page in a browser tab, asks them to copy the address by hand, and hands the next ten minutes of the visit to whoever has the patience left to retype it.

This post is the operational answer to the question every venue, agent, restaurateur and Airbnb host has when they think about putting a maps-link QR on a printed surface. What format does the QR actually encode. Which mode — single-place pin, or live directions from where the scanner is standing. Which provider opens on which phone, what happens when you try to force one, and the half-dozen real-world places this earns its keep before the print order even goes in.

A location QR code is just a maps URL behind a square#

The QR itself doesn't know anything about maps. It's a static or dynamic encoding of a URL, and the URL is the part that talks to the operating system. Three URL shapes do almost all the work:

1. A geo: URI — geo:40.748817,-73.985428 — the geographic equivalent of mailto: or tel:. Android picks it up natively and offers any installed maps app. iOS doesn't handle it without a third-party app, which is the reason geo: alone is a poor default in 2026.
2. A maps.apple.com URL — https://maps.apple.com/?q=...&ll=... — Apple's web URL scheme, which iOS opens in Apple Maps directly and which Android resolves as a normal web page (usually falling through to a browser or Google Maps depending on intent filters).
3. A google.com/maps URL — https://www.google.com/maps/search/?api=1&query=... — Google's URL spec, which Android opens in Google Maps natively and which iOS opens in Safari (or Google Maps if the user has it installed and set as the default).

The third route — Google's spec — is what most location QR generators encode by default, because it works everywhere even if not always in the user's preferred app. The trade-off is that an iPhone scanner gets bounced through Safari before landing in a map, which is two extra seconds and a wobblier experience than an Apple Maps deep link would give them. A platform-aware redirector behind the QR — the kind a Location QR code generator builds for you — looks at the scanner's User-Agent on the redirect and serves the Apple URL to iPhones, the Google URL to everyone else. That's the version that feels right on both phones, and it's the version this post is mostly about.

The two modes that matter for printed surfaces are single place and directions. The single-place mode drops a pin at the address and waits — the user can tap a Directions button if they want a route. The directions mode opens the routing engine immediately, with the destination filled in and the scanner's current location used as the origin. Each is right in different settings, and the wrong choice quietly halves the conversion of the QR you printed.

Single place or directions — the call that matters most#

The biggest decision is which mode the QR opens in, and it's the one most generators don't bother asking about. Single place drops a pin and waits. Directions opens routing immediately, with the destination pre-filled and the scanner's current location as the origin.

Single place is right when the scanner is already at the place. A wayfinding poster at a trade-show booth doesn't need to route the visitor — they're standing in front of it. A restaurant table card pointing at the venue's own location is decoration, not useful. A real estate yard sign at the property doesn't need to route to the property. In all of those settings, the right answer is to encode a destination the user can either save (Apple Maps "Add to Favourites"), share with a friend who's not yet there, or read the address from with the pin as context.

Directions is right when the scanner is somewhere else. An Airbnb welcome note pointing at the nearest laundrette assumes the guest is at the property and wants to walk somewhere. A tourism placard at a viewpoint pointing at the next viewpoint on the trail assumes the visitor is at the first and walking to the second. A restaurant flyer dropped in a hotel lobby pointing at the restaurant assumes the reader is at the hotel and wants to know how to get to dinner. In all of those, directions mode is the right default — the scanner saves a tap and a pinch-zoom and gets straight to the "twelve minutes on foot" answer they were going to look up anyway.

The mistake I see most often is using single-place mode for a directions-shaped problem. A restaurant prints its address QR on a billboard near the highway off-ramp, the driver scans, the map drops a pin five miles ahead with no route — the driver has to tap Directions, wait for their location, tap Drive, and the moment is gone. Directions mode would have put them on a route inside three seconds. The opposite mistake is rarer but real: a directions QR on a placard at the venue's own front door, which produces a "you have arrived" notification before the visitor has even walked inside.

The provider question — auto, Apple, or Google#

The default for a location QR code should always be auto. The redirector behind the QR reads the scanner's User-Agent header, decides whether the device is an iPhone, an iPad, an Android, or a desktop, and serves the right URL. iPhones get an Apple Maps deep link; Android phones get a Google Maps link that opens the native app; everyone else gets a Google Maps web URL because it's the most widely-installed fallback. The scanner ends up in the maps app they already use without ever seeing the redirect.

The harder question is what to do when auto isn't what you want. Two scenarios come up:

Force Apple Maps. A high-end venue whose visitor base is mostly American or Western European may want Apple Maps for everyone, on the bet that the iPhone scanners enjoy a native experience and the Android scanners can deal with a web map. The trade is real but small — Android users get a maps.apple.com page that renders in their browser and offers an "Open in Google Maps" button at the bottom. It works, but it's slower than the auto-routed default. Forcing Apple is only worth it if you have a specific reason to value Apple Maps' visual styling or its booking integrations.

Force Google Maps. The opposite trade — every scanner ends up in Google Maps even on iPhone. This used to be the right call when Apple Maps was new and unreliable. In 2026 the only reason to force Google is to use a Google-specific feature, the most common being Place IDs. A Google Place ID is a stable identifier for a real-world location that survives renames, address changes, and the venue moving down the block. If your QR points at a Place ID, Google can serve the right map even if the address has shifted; Apple's URL scheme doesn't have an equivalent. For chain restaurants and franchise locations where the address may change but the listing won't, Place IDs are the durable encoding.

The most common force case is neither of those, though. It's the workshop or training session where the scanner is sitting at a desk on a laptop — the QR has to open something, and "desktop browser scans a location QR" is a real case. Auto-routed redirects handle this by serving a Google Maps web URL to any non-mobile User-Agent, because that's the maps experience that works on every laptop without an install.

A maps mode picker#

The defaults — auto routing, single-place mode — are the right starting point for most signage. The picker exists for the cases where you have a specific reason to deviate.

The print surfaces this earns its keep on#

Five settings where a location QR code actively makes the printed surface more useful than it would be without one.

Real estate yard signs. The maps QR is the second QR most agents should be printing — the first being the listing photo gallery. A small directions-mode code labelled "Directions for Saturday's open house" beside the agent's name turns the yard sign into wayfinding for the open-house crowd driving in from neighbouring suburbs. The full real-estate operational picture is in QR codes for real estate listings — the agent's playbook, and the location QR is the supporting cast member that earns its keep on the open-house weekend itself.

Restaurant address cards and outdoor signage. Most restaurants print the street address on every card they ship — the takeaway menu, the business card, the entry on a paid listing in a tourist brochure. The location QR collapses the friction of reading the address, deciding which maps app to open, typing it in, and waiting for routing. For off-ramp billboards near a highway exit, the directions-mode QR is the difference between a hungry driver who passes the exit and a hungry driver who eats at the restaurant — covered alongside the rest of the outdoor physics in QR codes outdoors — billboards, bus stops, signage.

Trade-show booth wayfinding. A booth at a 30,000-square-foot convention floor lives or dies by people finding it. A maps QR on the pre-show invitation, the email signature, the LinkedIn post, and the lanyard insert that opens directions to the venue's address (with the booth number prominent on the landing page) makes the journey-to-booth measurable in a way "we're in Hall C, booth 412" never is. The full trade-show QR pattern, including per-day and per-rep codes for lead attribution, sits in QR codes for trade-show booths.

Tourism placards and trail markers. A heritage placard at a viewpoint pointing at the next viewpoint, a trail-head sign at the start of a walk pointing at the parking area on the way back, a museum exit sign pointing at the nearest tram stop — all directions-mode location QRs. The wider tourism playbook on what to print at heritage sites is in QR codes in tourism — multilingual signs and audio guides, and the multilingual case carries over directly — a multilingual QR code routing layer can serve a French-speaking visitor the maps URL with the right interface-language hint.

Airbnb and short-let welcome notes. This is the surface the maps QR was almost designed for. A printed welcome note in the apartment with three location QRs — "nearest laundrette", "best coffee on this street", "tram stop for the airport" — saves the host two text messages a week and gives the guest a better answer than typing place names into Google with patchy English keyboard skills. The wider onboarding pattern, where the maps QRs sit alongside the WiFi card and the check-out instructions, is in Airbnb guest onboarding via QR codes.

Restaurant table cards are a tempting sixth surface but they're usually wrong. A QR on the table pointing at the restaurant's own address is decoration — the diner is already there. Better uses of that table-card real estate are in QR codes for restaurant menus in 2026, where the takeaway-order and review-collection cases earn far more than wayfinding.

A maps QR is the moment a printed address stops being information and starts being a route. Print the address too, in plain text — the QR is for the scanner whose phone is in their hand, the text is for everyone whose phone isn't.

The print-the-address-too rule is important. A scanner whose phone is dead, whose camera is slow, or who's holding a paper menu over a candle they can't quite hold the phone in front of, needs the readable text as a fallback. The QR is an accelerator, not a replacement for the address line. Treat it the way the vanity URL beneath a real estate yard sign treats the printed URL — primary path is the scan, secondary path is the human-readable text underneath, and both go to the same destination.

What the directions URL knows about the scanner#

A directions-mode location QR opens routing from the scanner's current location. That location is read by the maps app from the operating system's location services, not from anything the QR or the URL controls. Apple Maps asks the user for permission once, the first time the app uses location, and reuses the answer for every future trip. Google Maps does the same. The QR doesn't get to see where the user is — it just opens the routing UI with the destination filled in and lets the OS handle the origin.

This is why the directions URL is privacy-light in the way many people don't expect. The redirector behind the QR sees the scanner's IP address and User-Agent — that's normal HTTP. It doesn't see the scanner's GPS location, because the GPS reading happens after the user is already in the maps app, after the redirect has finished. The location-services prompt belongs to Apple or Google, not to the QR platform. The platform's analytics show scan-count, country-level geolocation from the IP, and the device split between iOS and Android. They don't show "this scanner is at 14 Oak Street." That's a useful separation worth knowing about when explaining the QR to a venue's compliance team. The wider story of what scan analytics actually capture lives in the analytics docs.

For static QRs that encode a geo: URI directly (no redirector), even less is visible — the QR contains coordinates, the OS opens the maps app with them, and no server in the middle sees the scan at all. That's the right encoding for cases where you want the QR to work offline and don't need analytics, but it sacrifices the User-Agent-aware routing that makes the iPhone-vs-Android experience smooth on the same printed square.

The venue-moved problem#

The hardest operational question about a printed location QR is what happens when the venue moves. Static QRs that encode the latitude and longitude directly are stuck — the print is now wrong, and the only fix is reprinting every surface. Dynamic short links solve this the same way they solve every "the destination changed" problem: the QR encodes a short link, the redirector knows where the venue is today, and a one-line change in the dashboard moves every printed surface to the new address simultaneously.

This is the case where Google's Place IDs earn their keep. A Place ID is a stable identifier for a real-world location that Google maintains across renames, address changes and venue moves. A QR pointing at https://www.google.com/maps/search/?api=1&query=...&query_place_id=ChIJ... resolves to wherever Google thinks that place is today. For chain restaurants whose individual branches occasionally move within a block, or for venues whose street address changes when the building gets renumbered, Place IDs are the durable encoding. Apple Maps doesn't have a direct equivalent — its URL scheme accepts a coordinate pair or an address string, both of which can drift. The auto-routed redirector pattern (which serves Apple to iPhones and Google to Android) gives you the worst-case behaviour: iPhones get a coordinate that may drift, Android phones get the Place ID that doesn't. If your venue is move-prone, force Google and accept the iPhone-via-Safari trade.

The wider reason this matters — and the reason owning your link infrastructure is the right pattern for printed QRs — is that the redirector is the only piece you can update after the print run ships. Encode the venue's specific coordinates directly into the QR and you've bound yourself to that location for the lifetime of the printed surface. Encode a short link on your own domain and you've kept the option open.

How big does a location QR need to be#

The same size rules from outdoor signage carry over: the printed side length should be at least one tenth of the scan distance. A welcome-note QR in an Airbnb at arm's length needs about 2cm. A yard-sign directions QR at 3 metres needs about 30cm. A trade-show booth wayfinding QR at 8 metres of aisle distance needs about 80cm. The 1/10 rule is in QR codes outdoors with the full physics; for location-specific QRs the print constraints are identical to any other outdoor or arm's-length QR.

Encoding length matters because longer payloads need bigger QRs to stay scannable. A maps.apple.com URL with coordinates is roughly 60 characters. A Google Maps URL with coordinates is similar. A Place-ID URL pushes 90 characters, which puts the QR at version 5 or 6 — manageable but denser. A short link behind the QR (yourbrand.co/here) keeps the payload at 20 characters or less, which leaves the QR at version 2 or 3 — sparse, easy to scan, and easy to print small. Short-link encoding is the right default for any printed location QR; the long-form maps URL is what sits behind the short link on the redirector, not on the print. The general short-link case is in the short-links docs.

A static-vs-dynamic call for location QRs#

The static-vs-dynamic decision for location QRs comes down to two operational questions: will the venue move, and will the provider routing logic need to change. Both answers default to "eventually."

A static geo: URI that encodes coordinates directly works offline, works without any redirector, and works forever — as long as the venue stays at those coordinates. The moment the venue moves, every printed surface is wrong. A static maps.apple.com or google.com/maps URL has the same problem plus the platform-mismatch one (iPhone scanners hitting a Google URL, or vice versa).

A dynamic short link absorbs both. The venue moves — repoint the redirector. The provider logic needs to change (Apple Maps adds a new feature, Google adds a Place ID for the venue) — repoint the redirector. The print on the wall doesn't change. For any location QR that's going on a printed surface with a lifespan longer than the venue's certainty about its own coordinates, dynamic is the right call. For a one-off invitation card to a dinner party at a known address that won't change, static is fine.

The wider "should this QR be dynamic?" question, with its answers across QR types, sits in the QR codes docs — the location case lands the same way most others do, with dynamic as the default and static reserved for surfaces with short shelf lives.

FAQ#

Sourcesshow citations

• Apple Developer Documentation — Maps URL Scheme — https://developer.apple.com/library/archive/featuredarticles/iPhoneURLScheme_Reference/MapLinks/MapLinks.html
• Google Maps Platform — Maps URLs documentation — https://developers.google.com/maps/documentation/urls/get-started
• Google Maps Platform — Place IDs — https://developers.google.com/maps/documentation/places/web-service/place-id
• IETF RFC 5870 — A Uniform Resource Identifier for Geographic Locations ('geo' URI) — https://www.rfc-editor.org/rfc/rfc5870
• ISO/IEC 18004:2024 — QR code bar code symbology specification — https://www.iso.org/standard/83389.html
• Wikipedia — Geo URI scheme — https://en.wikipedia.org/wiki/Geo_URI_scheme
• UN Tourism (UNWTO) World Tourism Barometer — international arrivals data — https://www.unwto.org/un-tourism-world-tourism-barometer