# How to make one QR code do different things by device

> Encode a single URL on a domain you control and branch there: the server or a small script inspects the user agent and redirects iPhones to the App Store, Android to Play, and everyone else to a landing page. It works, but the redirect must stay alive as long as the print does.

Source: https://useqr.app/docs/how-to/how-to-make-one-qr-code-do-different-things-by-device · Last reviewed 2026-08-21 · UseQR is free forever, no signup.

---

## The architecture: one code, one URL, one branch point

A QR code cannot detect devices. It is inert data. The branching happens at the URL it
opens. So the pattern is always:

```
One printed code → https://example.com/get → inspect User-Agent → redirect
```

The classic use is app distribution: one code on the poster, iPhones land on the App
Store, Android lands on Google Play, laptops land on a page with both badges. The same
mechanism serves platform-specific deep links, OS-specific help pages, or
mobile-vs-desktop experiences.

## Client-side version (simplest to deploy)

A static HTML page at the encoded URL, a few lines of script:

```html
<script>
  var ua = navigator.userAgent;
  if (/iPhone|iPad|iPod/.test(ua)) {
    location.replace("https://apps.apple.com/app/id0000000000");
  } else if (/Android/.test(ua)) {
    location.replace("https://play.google.com/store/apps/details?id=com.example.app");
  }
  // no match: stay on this page, which shows both store badges
</script>
```

Falling through to a visible page with both buttons is the load-bearing detail. It is
your safety net for everything the sniffing gets wrong.

## Server-side version (cleaner)

A 302 issued by the server: a redirect rule, an edge middleware, or a
[tiny serverless function](/docs/developers/qr-codes-in-serverless-functions), avoids
the blank flash of the client-side page, works with JavaScript disabled, and gives you
a log line per scan, which is [free analytics](/docs/how-to/how-to-track-qr-code-scans)
into the bargain. Same logic, same fallback: anything unmatched gets the landing page,
not a guess.

## The honest caveats

- **User-agent sniffing is approximate.** The canonical trap: **iPadOS Safari requests
  desktop sites by default and identifies itself like a Mac**, so naive rules send
  iPads to your desktop page instead of the App Store. Treat misclassification as
  normal and let the fallback page absorb it.
- **You are now running a redirect service.** The printed code is only as alive as
  `example.com/get`. That endpoint must survive redesigns, replatformings and staff
  changes for the life of the print, the same permanence contract discussed in
  [changing what a code points to](/docs/how-to/how-to-change-what-a-qr-code-points-to).
- **Hosted "smart link" products carry platform risk.** Third-party device-routing
  services exist, but you inherit their lifespan: Google's Firebase Dynamic Links
  (once the standard answer here) was shut down in 2025. Ten lines on your own domain
  have no such expiry; the general argument is in
  [static vs dynamic](/docs/basics/static-vs-dynamic-qr-codes).

For the common app-install case, start from the
[app download QR generator](/app-download-qr-code); for anything custom, encode with
the [URL generator](/url) and confirm the final payload in the [validator](/validate).
Then test the full matrix before printing: an iPhone, an Android phone, an iPad (it
will surprise you), and a laptop.

## FAQ

### Can a QR code detect what phone scanned it?
No: the code is static data. The detection happens at the URL it opens, where a server or script inspects the browser's user agent and redirects accordingly.

### How do I make one QR code open the right app store?
Encode a URL you control; at that URL, redirect Apple devices to the App Store, Android to Google Play, and show everyone else a page with both badges. The fallback page catches every device the rules misread.

### Why does my iPad get the wrong destination?
iPadOS Safari requests desktop websites by default and presents a Mac-like user agent, so simple rules classify iPads as desktops. Design the fallback page to serve them well rather than fighting the user agent.

### Is there a service that does device routing for me?
Several exist, including dynamic QR platforms, but the printed code then depends on their continued operation, and such services do shut down. A short redirect on your own domain does the same job without an expiry date you don't control.

## Try it

- https://useqr.app/url
- https://useqr.app/app-download
- https://useqr.app/validate