New:Experimental free plan now live for everyonev1.6.0

Ok1Second
Menu
Guide

How to add conditional redirects to a QR code

A conditional redirect sends scanners to different pages depending on who they are — their country, device or language — all from the same printed code. It is what lets one print run serve several markets without several codes.

Updated October 6, 2026 · 5 min read

How rules are evaluated

Each rule declares one or more conditions. When a scan arrives, rules are checked from the highest priority down and the first match wins — the ones below it are never evaluated. A default destination catches everyone else.

Because the decision happens on the server at scan time, rules need a dynamic code. A static code has the URL baked into the pattern and there is nothing to evaluate.

  • Country — ISO codes such as US, DE, FR
  • Device — mobile, tablet or desktop
  • Operating system — iOS, Android, Windows, macOS
  • Language — the browser's preferred language

What you can actually match on

The useful conditions are the ones a browser or a phone reveals without asking the visitor anything. Country comes from IP geolocation and is right most of the time; device and OS come from the user agent; language comes from the Accept-Language header the browser already sends.

None of these is perfect. A traveller on a roaming SIM may resolve to the wrong country, and a browser set to English on a phone bought in Spain will ask for English. That is why rules are a routing convenience rather than a guarantee, and why the default destination has to be usable on its own.

  • Country: accurate for fixed lines and most mobile networks, unreliable for VPNs and roaming
  • Device: reliable for phone versus desktop, less so for tablets
  • OS: reliable enough to split an app-store link
  • Language: only as good as the reader's browser settings

Ordering and fallbacks

Make specific rules higher priority than broad ones. A rule matching German iOS users should outrank a general mobile rule, because the specific one is more likely to be what you meant; if the broad rule came first it would swallow the scan and the specific rule would never run.

Always set a default. A scan with no country, an unrecognised language or a crawler hitting the code from a data centre still has to land somewhere sensible, and the default is what stops a rule set from turning into a dead end.

  • Specific before general: country plus device outranks device alone
  • One rule, one intent — do not nest unrelated cases in a single rule
  • A default destination that is valid for any reader, in any country
  • Fewer rules ordered well beat many rules that overlap

Setups that earn their keep

Three patterns cover most real cases: one print run for several markets, one package for several languages, and one poster for two app stores.

In each case the value comes from printing once. Every rule you add is cheaper than a second artwork, a second print run and a second code to manage.

  • Market split: country rules send US scans to the US store and everyone else to the EU page, with the EU page as the default
  • Language split: language rules send de/fr/es/nl readers to local pages, with English as the fallback
  • App install: OS rules send iOS to the App Store and Android to Play, and desktop to a page that explains the app

Testing rules before you print

Rules fail quietly: a bad order or a typo in a country code still sends the visitor somewhere, just not where you intended. Test each branch before the print run by opening the code from the source you are trying to match — a VPN for another country, a phone and a laptop for the device split — rather than trusting the dashboard preview.

Check the default path deliberately too, by simulating a scan that matches nothing. It is the branch most likely to be forgotten and the one that catches real visitors.

  • Scan from at least two countries (a VPN is enough) to prove the country rule fires
  • Scan from a phone, a tablet and a desktop to prove the device rule fires
  • Trigger the unmatched case on purpose to see where the default sends people
  • Re-test after every rule change — a new rule can shadow an old one

Frequently asked questions

Can a rule match more than one condition?
Yes. A rule can require a country and a device at the same time, so precise combinations are possible — a German iPhone and a German desktop can receive different pages.
What happens if no rule matches?
The visitor is sent to the default destination, which is why setting a sensible default matters. Without one, a scan your rules did not anticipate has nowhere to go.
Do conditional redirects work on static codes?
No. Rules require a dynamic code, because the decision is made on the server at scan time. A static code's URL is encoded in the pattern itself.
How many rules should one code have?
As few as cover your real cases — usually three to six. Because the first match wins, a long list of overlapping rules hides which one actually fired and makes the code hard to debug.
What if a browser reports an unexpected language?
The rule simply will not match and the scan falls through to the next rule or the default. Treat language as a best-effort signal, not as a reliable identifier of where a person is from.
Can I test a rule without printing?
Yes — scan the code from a VPN and from different devices to exercise each branch. The dashboard preview tells you the rules exist; only an actual scan tells you which one wins.

Keep reading

Ready to create one?

Dynamic codes are editable forever from €3/month.

Create your first dynamic QR code

Free to start. One code, editable forever, with scan tracking from the first scan.

Privacy-first analyticsNo per-scan feesEdit links anytimeNo contract