How to Create a QR Code for a Location, GPS, or Map

The decision matrix below maps the five formats to the print context that fires them.

Yard signs and real estate signage. Google Maps URL pointed at the listing address. The audience walks up to the sign, scans, gets navigated to the listing. iOS users with the Google Maps app land in Google Maps; iOS users without it land in the maps.google.com web view (which still routes correctly). The fallback web view is the deliberate trade — it covers 100% of scanners at the cost of 1 extra second on the first scan.

Trailheads, outdoor venues, parking lots. GPS coordinates as a geo: URI. There's often no clean street address for a trailhead or a lot entrance. The geo URI puts the user at the exact coordinate, native iOS and Android handling. Print the readable lat/lng as a fallback.

Event signage and conference venues. Google Maps URL pointed at the venue name (e.g., https://www.google.com/maps?q=Javits+Center+New+York). Names rank better than coordinates in user mental models — most people can't read a latitude pair, but everyone knows what 'Javits Center' is. Use names when the venue is identifiable; coordinates when it isn't.

Business cards and vCard QRs. A vCard QR with the office address as the ADR field, not a separate location QR. The vCard format puts the address directly into the recipient's contact entry, which most users prefer over a one-off map link. Skip the dedicated location QR here.

Hotel and hospitality. Google Maps URL plus a separate Apple Maps URL on the same printed card, labeled 'Android' and 'iPhone' respectively. The two-QR pattern adds 30% to the print footprint but eliminates the cross-platform fallback friction.

Packaging with international audiences. Plain text address. Country-specific map apps (Baidu in China, Yandex in Russia) handle plain addresses via their default browsers, but they don't handle goo.gl/maps short links or Apple Maps URLs natively. The lowest-friction format for genuinely international audiences is text.

Ride-share campaigns. Uber or Waze deep links. Useful for nightlife venues, airports, and 'get a ride home' campaigns at events.

Google Maps URLs come in four shapes, each with different user behavior. Pick deliberately.

The `?q=` search URL. Pattern: https://www.google.com/maps?q=Javits+Center+New+York or https://www.google.com/maps?q=40.7484,-73.9857. Opens Google Maps with the search term pre-filled. The user lands on the matching pin and taps Directions themselves. Works for both addresses and coordinates. The most flexible single format.

The directions URL. Pattern: https://www.google.com/maps/dir/?api=1&destination=550+W+26th+St,+New+York,+NY. Opens Google Maps directly into directions mode with the destination set, asking the user to confirm their current location as the origin. One tap closer to navigation than the search URL. The right pick when the print context is 'get directions here right now' (yard sign, event signage, brick-and-mortar wayfinding).

The shared short link. Pattern: https://goo.gl/maps/XXXXX or https://maps.app.goo.gl/XXXXX. Generated by tapping Share in the Google Maps app. Shortest URL, cleanest QR pattern, but ties your campaign to Google's URL shortener — if they retire the shortener (as they did with goo.gl in 2019), the links break. For long-life printed assets (a metal yard-sign that lasts 5 years), the long-form ?q= URL is more durable.

The embed URL. Pattern: https://www.google.com/maps/embed?.... Designed for iframe embedding, not for QR scanning. Skip.

Practical recommendation. Default to the ?q= search URL for general use and the dir/?api=1 directions URL when navigation is the explicit goal. Avoid short links for printed assets that live longer than 12 months. Avoid the embed URL entirely for QR generation.

Apple Maps URLs use the pattern https://maps.apple.com/?address=... or https://maps.apple.com/?ll=40.7484,-73.9857. On iOS, the URL opens directly in the Apple Maps app. On Android, the URL opens in a browser at maps.apple.com — which renders a degraded map view, not the same experience as Google Maps on Android.

The cross-platform reality: a pure Apple Maps URL costs ~50% of Android scanners a clean experience. For audiences split between iOS and Android, the right answer is one of two patterns.

Pattern A — Google Maps default, accept the iOS web view. Encode a Google Maps URL. iOS users with the Google Maps app installed get the native experience. iOS users without it (the majority on iPhones) get the Google Maps web view, which still routes correctly via the web client. Android users get native Google Maps. Trade-off: iOS users see 'Open in Google Maps' or fall back to web; no native Apple Maps experience for any user.

Pattern B — print two QRs labeled 'iPhone' and 'Android'. Encode an Apple Maps URL for one, a Google Maps URL for the other. Label each QR clearly. The user picks the right one for their phone. Trade-off: doubled print footprint, slight cognitive load. Worth it for premium hospitality and events targeting iPhone-heavy audiences.

Pattern C — universal map links via [Maps URL Universal Links](https://developer.apple.com/library/archive/featuredarticles/iPhoneURLScheme_Reference/MapLinks/MapLinks.html). Apple's universal Maps links syntax — maps.apple.com/?q=... — is meant to be cross-platform, but Android handling is still a browser fallback in practice. The technical promise of the universal link doesn't deliver native Apple-Maps-on-Android.

For most SMB and SMB-leaning hospitality, Pattern A (Google Maps default) is the right call. For premium hospitality, real estate, and any iPhone-leaning audience, Pattern B (two QRs) is worth the print footprint.

Beyond the default map apps, two ride-share-adjacent destinations matter for specific contexts: Waze for traffic-aware routing, Uber for direct ride booking.

Waze deep links. Pattern: https://waze.com/ul?q=550+W+26th+St,+New+York for a search-style destination or https://waze.com/ul?ll=40.7484,-73.9857&navigate=yes for direct lat/lng navigation. On phones with Waze installed, the URL opens the app directly and starts navigation. Without Waze installed, the user lands on the Waze web view or app store install prompt.

Waze QRs make sense for: nightlife venues that draw drivers, suburban event venues with traffic-sensitive arrival windows, drive-through pickup zones at busy retail. The audience selection — Waze users skew toward heavy commuters and traffic-conscious drivers — makes this format more niche than Google Maps but more valuable when the audience matches.

Uber deep links. Pattern: https://m.uber.com/ul/?action=setPickup&pickup=my_location&dropoff[formatted_address]=550+W+26th+St,+New+York,+NY. Opens the Uber app with the destination pre-filled and the pickup set to the user's current location. The user reviews fare and ride type, taps Confirm.

Uber QRs work for: event signage with 'get a ride home' campaigns, hotel front desks for guest convenience, late-night entertainment venues where driving impaired is a known risk. Pair with the Lyft deep link for audiences who use both.

The right pattern for these. Don't replace your Google Maps QR with a Waze or Uber QR — supplement it. The primary location QR points at Google Maps (the universal-fallback default). A secondary QR labeled 'Get a ride' opens Uber or Waze for the specific use case. Three QRs on a single piece of signage is the upper limit of cognitive load; pick the two that match your audience.

See the dynamic vs static guide for the trade-off when these ride-share URLs need to evolve (e.g., a venue changing pickup point seasonally).

Most location QRs should be static. The destination — your address, your venue, your trailhead — doesn't change month-to-month. Static codes encode the URL directly into the QR pattern, work forever without a server, and cost nothing on EZQR. No subscription, no monthly fee, no risk of cancellation killing the printed asset.

The exceptions where dynamic is worth $5/month on the Lite plan are real but specific.

Pop-up retail and event venues that move. A food truck rotating between three locations weekly. A pop-up market that occupies different parking lots seasonally. A traveling exhibit. The dynamic QR points at a redirect that you repoint at the current location each week. The single printed asset works across every location.

Construction and event staging. Multi-phase construction sites where the entry point moves as the project progresses. Festival staging where today's check-in is at gate A and tomorrow's is at gate B. The dynamic QR survives the staging changes without reprinting.

Multi-location chains with shared marketing. A regional restaurant chain that runs the same printed campaign across 12 locations. Each location's QR is dynamic, pointing at that location's Google Maps URL. The shared print template stays the same; the dynamic backend handles per-location routing.

Scan analytics. When you need to know how many people scanned the QR, where they were, and what device they used. Static codes have zero analytics by design. Dynamic codes record every scan event. For a yard sign deployed at scale (200 listings across a market), the per-listing scan data informs which signs work.

For the majority of deployments — one fixed venue, one stable address — static is the right answer. Subscription-free location QR is the default; dynamic is the exception. See the permanent QR code guide for the cancellation-survival angle that makes static the safer default for long-life printed assets.

Location QRs live on more diverse print surfaces than most QR types — yard signs, packaging, business cards, event signage, vehicle wraps, building wayfinding. Each context has a different sizing rule.

The 10:1 distance rule. QR width should be at least 1/10 the typical scanning distance, with a 1.5× safety margin. A yard sign scanned from 5 feet away needs a QR at least 5 inches × 5 inches. A business card scanned from 6 inches needs at least 0.6 inches × 0.6 inches. Underpowered QRs are the most common location QR failure — the code is technically present but too small for the actual scanning distance.

Yard signs and real estate signage. 4–6 inches QR width, printed on the lower-right of the sign at standing eye level (~5 feet from ground for adult viewing). Add 'Scan for directions' as the adjacent CTA.

Event signage and conference venues. 8–12 inches QR width for wall-mounted signs scanned from 6–10 feet away. Mount at 5–6 feet from ground. Pair with the readable typed address as fallback for users who can't scan.

Business cards. 0.6–0.8 inches QR width on the back of the card. Pair with the vCard QR rather than a standalone location QR — the vCard format puts your address into the recipient's contacts directly.

Vehicle wraps. 6–12 inches QR width depending on scan distance. Avoid placing on curved surfaces (door frames, hoods) — the curvature distorts the QR and breaks scanning. Use flat panels (rear bumper, rear window).

Packaging. 0.5–1 inch QR width. The print context is usually scanned at arm's length. Position consistently across the SKU line so the location QR always sits in the same spot.

The fallback typed text rule. Always print the readable address or destination name below the QR. Two reasons: it covers scanners on older devices that fail to read the QR, and it serves as visual confirmation for the scanner that they're about to navigate to the right place. A QR with no fallback text reads as 'trust me, just scan it' — a friction point for new users.

Five failure modes account for the majority of location QR problems we see in real deployments.

Wrong format for the audience. An Apple Maps URL on a yard sign in a market where 60% of scanners are Android. The QR works for the iPhone half; the Android half lands on a degraded web view and abandons. Symptom: scan-to-direction conversion is roughly 50% of expected. Fix: switch to Google Maps URL.

Short link expiration. A Google goo.gl/maps/... short link printed on a metal yard sign that outlives the shortener. Google's goo.gl shortener was deprecated in 2019; existing links still work, but new shorteners are deprecated periodically. Symptom: QR scans return a 404 or 'link expired' message. Fix: re-encode with the long-form ?q= URL pattern.

Coordinate typos. A latitude/longitude entered with the decimal point in the wrong place — 40.7484 becomes 407.484. The geo: URI parses, the map app accepts it, and the user lands 27,000 kilometers from the intended location (somewhere over the Pacific Ocean). Symptom: scanners arrive at a nonsense destination and rage-quit. Fix: copy coordinates from Google Maps directly (right-click on the pin → copy coords) rather than typing.

Hidden destination changes. A static QR printed for a venue that moved to a new address. The static code still encodes the old address. Symptom: scanners arrive at the old location. Fix: this is the canonical case for dynamic QR codes — repoint without reprinting.

Address ambiguity across markets. '550 Main St' resolves to a different location in every market. International audiences scanning a US-formatted address may land in their own country's '550 Main St' if the URL doesn't disambiguate. Fix: always include city, state/province, and country in the address string. Better still, use coordinates for international-audience signage.

The size-too-small failure. A QR printed at 0.5 inches on a yard sign scanned from 6 feet away. Symptom: scanners get the camera close enough to read but never get a focus lock; the scan times out. Fix: redo the math at 1/10 of the scanning distance with a 1.5× safety margin.

For the broader troubleshooting context when QR scans fail without obvious cause, see why QR codes stop working.