The Technology Behind Device Detection in QR Codes

You scan a QR code on your iPhone. It opens the App Store. Your friend scans the same code on their Android phone. It opens the Play Store. Same QR code, different destinations. How does that work?

The answer lies in a clever combination of server-side redirects, User-Agent parsing, and fallback logic. Let's pull back the curtain on the technology that makes smart QR codes possible.

The Anatomy of a Smart QR Code

First, let's clear up a common misconception: QR codes themselves don't detect anything. A QR code is just encoded data—typically a URL. The "smart" part happens on the server that URL points to.

Here's the flow:

The magic happens in step 3. When your browser requests a URL, it sends along a bunch of information about itself. The most important piece? The User-Agent header.

Understanding User-Agent Strings

Every HTTP request includes a User-Agent header that identifies the browser and operating system. Here's what they look like in practice:

iPhone (Safari)

Android (Chrome)

Desktop (Chrome on macOS)

Notice the patterns? The server can look for keywords like iPhone, iPad, Android, Windows, or Macintosh to determine the device type.

The Detection Algorithm

At its core, device detection is pattern matching. Here's a simplified version of how it works:

Simple, right? In practice, it gets more nuanced. You need to handle edge cases like:

• Android tablets vs phones — both say "Android" but might need different handling
• iPadOS — newer iPads report as "Macintosh" in Safari to request desktop sites
• Desktop browsers with mobile emulation — developers testing responsive designs
• Unusual browsers — Facebook in-app browser, Instagram WebView, etc.

The Redirect Logic

Once the server knows the device type, it performs an HTTP redirect. There are two main approaches:

302 Temporary Redirect

The most common approach. The server responds with a 302 status code and a Location header pointing to the destination.

This is what KuhArr uses. It's fast, works everywhere, and doesn't cache the redirect (so the same URL can redirect differently for different users).

JavaScript Redirect

Some services render a page that uses JavaScript to detect the device client-side:

Handling Edge Cases

Real-world device detection isn't always clean. Here are the tricky scenarios and how to handle them:

The iPadOS Problem

Starting with iPadOS 13, Safari on iPad reports itself as a Mac to get desktop websites by default. The User-Agent looks like this:

No mention of iPad anywhere! The workaround? Check for touch support:

For server-side detection, you can also check for the presence of Mobile in the User-Agent or use the newer Sec-CH-UA-Platform client hints header if available.

In-App Browsers

When someone scans a QR code in Instagram, Facebook, or TikTok, it opens in an in-app browser. These have their own User-Agent quirks:

The good news: they still include the base platform (iPhone/Android), so detection still works. The challenge: deep links and app store redirects can behave differently in WebViews.

The Desktop Fallback

What happens when someone scans your app QR code on a laptop with no camera app? They might manually type the URL or click a link. You need a sensible fallback.

Options include:

• Redirect to a landing page with links to both app stores
• Redirect to your web app (if you have one)
• Show a "Download our app" page with QR code for their phone

The Priority Chain

Smart QR services typically implement a priority chain for redirects. At KuhArr, ours looks like this:

Each step falls through to the next if not configured. This gives you maximum flexibility while ensuring there's always somewhere to send the user.

Performance Considerations

Redirects add latency. Every millisecond matters when someone is waiting for a page to load after scanning a QR code. Here's how to keep things fast:

Edge Computing

The redirect server should be as close to the user as possible. Services like Cloudflare Workers, Vercel Edge Functions, or AWS Lambda@Edge let you run detection logic at the edge, reducing round-trip time from hundreds of milliseconds to single digits.

Keep Detection Simple

Don't over-engineer the detection. Complex regex patterns or multiple database lookups slow things down. A few string comparisons are all you need for 99% of cases.

Cache Wisely

You can't cache the redirect response (each user might get a different destination), but you can cache the destination URLs. Pre-warm your redirect service with the target URLs to avoid cold-start delays.

Privacy and Analytics

Device detection happens passively from the User-Agent header—you don't need cookies or tracking scripts. This means:

• No consent required — User-Agent is sent automatically with every request
• No personal data collected — you learn the device type, not who's using it
• Anonymous analytics are possible — count scans by device without identifying users

At KuhArr, we count scans and device breakdowns without storing IP addresses or creating user profiles. You get actionable data (which platform needs more marketing?) without the privacy concerns.

The Future: Client Hints

User-Agent strings are a mess—a legacy of browser wars and compatibility hacks. Google is pushing for Client Hints, a cleaner alternative:

Client Hints are structured, easy to parse, and privacy-preserving (you request only the hints you need). The catch? They require HTTPS and explicit server opt-in. Adoption is growing, but User-Agent parsing isn't going anywhere soon.

Try It Yourself

Want to see device detection in action? Create a smart QR code with KuhArr and scan it from different devices. You'll see how the same QR code seamlessly routes iOS users to the App Store, Android users to the Play Store, and desktop users to your website.