under the hood
A QR code just carries text. The interesting part is what that text points at. Point it at a short link and a tiny server gets to make decisions every time it's scanned. Here's the whole journey — scroll on.
Heads up: dottr itself is only the generator — it draws your code right here in the browser and never runs a server. This is how the short-link services we recommend (and the redirect product we're building) do their bit.
Someone taps your short link
They scan the QR or tap something like dottr.to/menu. To them it looks like any other link — but it doesn't point straight at your page.
The request reaches a redirect server
A raw URL points directly at the destination. A short link instead points at a tiny redirect server — that detour is where all the cleverness happens.
Just a computer that's always switched on, sitting in a data centre waiting to answer requests. Your phone asks for a page; the server answers.
Pretty much — no screen or keyboard, its whole job is to wait for requests and reply, day and night.
It reads the slug
The bit after the slash — menu — is the slug. The server pulls it off the request to know which link was tapped.
Old newsroom slang for a story's short name. On the web it just means the readable tail of an address — menu in dottr.to/menu.
It looks the slug up in a database
One quick lookup finds the record for that slug: the real destination URL, plus any rules you've set and a tally of scans so far.
Think of a giant, super-organised spreadsheet the computer can search in a blink. Each short link is one row (a “record”): the slug, where it points, who owns it, how many scans.
It keeps an index — like the index at the back of a book. Instead of reading every row, it jumps straight to the slug it wants.
There's a separate users table — one row per person. You sign in, and the system only hands back the records tagged with your account.
Scrambled, never as-is. It's run through a one-way hash, so even the people running the service can't read it back.
Your role. A normal user only sees their own links; an admin can see more. The database checks your role before handing anything over.
It reads the request headers
Every request carries headers — including the User-Agent, which reveals the device, operating system and browser. The server gets to peek at that before deciding anything.
A little label every browser tacks onto its request describing itself — roughly “iPhone, Safari” or “Windows, Chrome”. Nothing you type; it's just along for the ride.
It decides where to send you
Now it can route by device: send iOS visitors to the App Store, Android visitors to Google Play, and everyone on a laptop to your website — all from the one printed code.
Not really. Reading “this is an Android” to pick a destination is different from tracking, which means building a profile of you over time. Routing can happen without storing anything personal.
It redirects — and counts the scan
The server replies “go here”, the visitor lands on exactly the right page, and the scan is logged. Change the destination tomorrow and the same printed QR just follows along.
Usually just a tally — and maybe the time, rough region and device type. Aggregate numbers, not your name. (Exactly what's kept depends on the service.)
The payoff: one link, three destinations
The server read the User-Agent, matched the rule, and sent each visitor where it makes sense — from the single QR you printed.
One code, many behaviours
iOS, Android and desktop can each land somewhere different — without ever reprinting.
Change it anytime
The printed QR is permanent; the destination behind the slug isn't. Re-aim it in seconds.
You can see the scans
Because every tap passes through the server, it can count them — so you learn what actually worked.
None of this happens on dottr's servers, because dottr doesn't have any — the code above is drawn in your browser. To get the redirect smarts, point your code at one of the short links we rate. A dottr redirect product is on the way.