Rule-based dynamic QR codes, explained
A rule-based code decides its destination at scan time. Understanding how matchers, priority and fallbacks interact is the difference between predictable routing and a support ticket.
Updated October 6, 2026 · 4 min read
The four matchers
Each rule can test the signals a scan actually carries. You combine as many as you need on a single rule.
All four signals come from the request the phone makes, not from anything you install or ask the reader to consent to. That is why rule-based routing works with no app, no SDK and no cookie — and also why it can only ever be as accurate as the request itself.
- Country — ISO codes such as DE, FR or US
- Device — mobile, tablet or desktop
- Operating system — iOS, Android, Windows, macOS
- Language — the browser's preferred language
Priority decides the winner
When several rules could match, the highest priority wins; ties fall back to the oldest rule. Put specific rules above broad ones so a precise match is not swallowed by a catch-all.
Think of the list as a decision order rather than a set of filters. Each rule is asked in turn and the first one that matches is applied — rules below it are never even evaluated, so a broad rule placed too high makes everything under it dead code.
- Highest priority first, then oldest wins a tie
- Specific above general: country plus device outranks device alone
- A broad rule near the top silently disables the rules below it
Always set a fallback
Detection is an estimate. Some scans carry no country, unusual devices report nothing, and browsers send surprising languages. The default destination is what keeps those scans useful.
Without a default, an unmatched scan has nowhere to go — and the failures are invisible, because nothing in the dashboard reports 'a scan arrived that matched nothing' unless you deliberately test for it.
Combining conditions without overfitting
Conditions on one rule are combined with AND: a rule requiring Germany and iOS matches only a German iPhone, not a German Android and not an American iPhone. That precision is useful, but it multiplies quickly.
Four countries times two platforms is eight combinations, and each one is a rule to write, order and test. Prefer a few broad rules with a good default over a matrix that tries to name every case — the matrix is harder to keep correct and its gaps are exactly where real visitors land.
- AND within a rule, first-match-wins between rules
- Each extra condition doubles the combinations to reason about
- One broad rule plus a sensible default beats a sparse matrix
Where detection is weakest
Knowing where the signals fail is what makes a rule set predictable. Country detection comes from IP geolocation: reliable on fixed lines and most mobile networks, wrong for VPN users, travellers on roaming SIMs and anyone behind a corporate gateway that egresses in another country.
Device and OS come from the user agent, which browsers and privacy tools increasingly trim or standardise to avoid fingerprinting — so a tablet may report as a desktop, and an unknown browser may report nothing at all. Language is the browser's stated preference, which is frequently the language of the operating system rather than the language the person reads comfortably.
- Country: VPN, roaming and corporate egress all break it
- Device: tablets and desktop-mode browsers report inconsistently
- OS: heavily reduced by privacy browsers
- Language: a browser setting, not a statement about the reader
Frequently asked questions
Can a rule match more than one condition?
How accurate is country detection?
Do rules work on static codes?
What happens when two rules have the same priority?
How many rules should a code have?
Can I test rules before printing?
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.