How URL Shorteners Work: Redirects, Lookups and Analytics

A URL shortener does one thing: it remembers a long address under a short name and, when someone asks for the short name, sends them on to the long address. Everything else you'll meet — click counts, custom domains, passwords, QR codes — is built on top of that single lookup. Once you understand the lookup, most of what you'll ever notice about a short link stops being mysterious: why some are slow, why click numbers differ between services, why a link can be changed after it's printed, and what a short link can and cannot hide.

This guide walks through the whole path from click to destination. It's written for people who use short links — marketers, publishers, anyone who prints a QR code — rather than for people building a shortener, but it doesn't skip the mechanism, because the mechanism is where the answers are.

The two halves: storing and redirecting#

When you shorten https://example.com/products/spring-collection?utm_source=newsletter&utm_campaign=spring, the shortener writes that address into a database next to a key. The key is either generated — a handful of random characters such as kZHTt5 — or chosen by you, such as spring. The short link is nothing more than the shortener's domain followed by that key: xlyl.link/spring.

Later, someone taps the short link. Their browser asks the shortener's server for /spring. The server looks the key up, finds the long address stored beside it, and replies with an HTTP redirect: a response that says, in effect, "what you want is over there", and includes the long address. The browser follows it on its own. The visitor sees the destination; the short link was on screen for a few milliseconds and most people never notice it was there.

That is the entire mechanism. A URL shortener is a lookup table with a web server in front of it. Everything in the rest of this guide is a consequence of that sentence.

Why the key matters more than it looks#

Two details about the key shape the rest of the product.

First, keys are unique per domain, not globally. The real lookup is domain plus key, which is why xlyl.link/spring and go.yourbrand.com/spring can point at different places, and why moving to your own domain frees up every alias you'd want.

Second, a generated key is only as good as its randomness. A shortener that hands out a1, a2, a3 in order lets anyone enumerate every link it has ever made by counting. Well-built services generate keys from a large alphabet with enough length that guessing one is impractical, and treat a custom alias as a deliberate choice to make a link findable rather than private. If a link must be private, the answer is a password on the link, not an obscure key.

301, 302 and 307: which redirect, and why it matters#

HTTP has several ways to say "over there", and the choice changes how a short link behaves.

These are not conventions — they are defined in RFC 9110, the HTTP semantics specification, and MDN's redirections guide covers how browsers treat each one in practice.

Shorteners that count clicks use a 302 or 307 on purpose, and the reason is the caching column. If the browser cached a 301, the second click from the same person would never reach the shortener, and would never be counted. Worse, if you later changed where the link goes, that person's browser would keep sending them to the old destination until its cache expired — which can be a long time.

A 302 costs one extra round trip on every click. On a well-run service that's tens of milliseconds. It buys two things you'll use constantly: an accurate count, and the ability to change the destination later with every visitor getting the new one.

There's a search-engine angle too. A 301 passes ranking signals to the destination and is what you'd use to move a page permanently. A 302 from a short link tells crawlers the short link is not the canonical address — which is exactly right, because it isn't. Your content's page should rank; the short link is a door to it.

Where the analytics come from#

Because every click passes through the shortener's server, the server can note a few things about the request before it redirects. This is the entire data source for link analytics; nothing runs on the destination page, and nothing is installed on the visitor's device.

What a request carries:

• The time. Every click has a timestamp, which is where "clicks per hour" and "clicks per day" come from.
• The Referer header. The page the click came from — a newsletter, a social network, a search result. Browsers send only the host (or nothing) in many cases now, so referrer data is coarse: you'll see instagram.com, not the particular post.
• The User-Agent header. The browser and operating system, from which "mobile or desktop" and "Safari or Chrome" are derived.
• The IP address. From which a country, and sometimes a region, can be looked up. A shortener that respects privacy uses the address for that lookup and then discards it; Xlyl never stores visitor IPs.

Two consequences follow, and both are why link analytics are worth having alongside whatever runs on your website.

Link analytics work for destinations you don't control. A short link to your Amazon listing, your podcast on Spotify, a partner's registration form or a PDF on a CDN tells you how many people went there, from where and when — pages where you can't install anything.

Link analytics measure the click, not the visit. Someone who taps and then closes the tab before the page loads is a click but not a page view. Someone whose browser blocks your site's analytics script is a click but not a page view. Link counts are always a little higher than page analytics for the same traffic, and the gap is real people, not an error.

Bots, and why honest numbers are lower#

The moment a link is pasted into a chat app, a social network or an email client, something fetches it. Link-preview crawlers visit every URL to build the little card with a title and image. Security scanners in corporate mail systems fetch every link in every message. None of these are people.

A shortener that counts every request will report phantom clicks — sometimes several per real one on a link shared widely in chat. A shortener that filters known crawlers by their User-Agent and behaviour reports lower numbers that reflect humans. When two services disagree about the same link, this is almost always why. Xlyl filters bots before counting, and while it keeps a row for each click, the visitor's IP address is used only in memory and never written down — so there is no address in the database to leak.

Custom domains: same lookup, different front door#

A custom domain doesn't change the mechanism at all. You point go.yourbrand.com at the shortener's server with a DNS record — an A record for a root domain, a CNAME for a subdomain. When a request arrives for that hostname, the server looks the key up in the same table, scoped to your domain, and redirects exactly as it would for its own domain.

What changes is everything the visitor can see:

• The link carries your name, which is why branded links are trusted and tapped more than a stranger's domain.
• The alias namespace is yours. go.yourbrand.com/sale is available even if a thousand other people have used /sale elsewhere.
• Your links survive the shortener. If you ever move services, the domain moves with you and old links can be re-pointed.

The custom domain guide covers the DNS step by step; the domains page in the dashboard checks the records live so you can see whether the domain is pointing at the right place before anyone clicks.

Passwords, expiry and previews#

Anything that happens between the lookup and the redirect is a feature. Three common ones:

Password protection. Instead of redirecting, the server shows a form. Only when the submitted password matches does it redirect. This is real protection — the destination is never sent to the browser until the password is right — which is not true of an "obscure" link, whose destination is one preview away. Password-protected links suit previews, drafts and anything you'd rather not have forwarded.

Expiry. A timestamp on the stored record. Once it passes, the lookup behaves as though the link never existed, and the visitor gets a not-found page. Expiring links are the right tool for time-boxed offers, event registration and download links you don't want circulating forever.

Preview. Adding + to the end of an Xlyl link returns a page showing the destination instead of redirecting to it. It's the quickest way to check where a short link goes before you follow it, and it's what a careful reader should do with any short link from someone they don't know.

Why some short links are slow#

If the lookup is a database query on every click, a busy shortener is doing a great many queries. Fast services keep their popular links in memory — a cache in front of the database — so the common case never touches disk. Xlyl uses Redis for this; a link that's being clicked a hundred times a minute is served from memory, and each click is written to the database afterwards by a background job, off the redirect path.

Slow services either don't cache, or are doing extra work on the redirect path. The usual suspects:

• An advertising interstitial — a page you have to sit through before the redirect. This is how "free" shorteners that show ads make money, and it's a tax on every one of your visitors.
• A tracking pixel or third-party script on an intermediate page.
• A synchronous fraud or safety check that calls out to another service before answering.

If a short link takes a visible moment to resolve, one of those is usually why, and it's worth knowing before you put the link on a billboard. A free shortener with no interstitial is a different product from one that shows ads on the way through.

What a short link cannot hide#

The destination is in the redirect response, so anyone who looks can see it before visiting: with a preview feature, with the browser's network inspector, or with a one-line command. curl -I xlyl.link/spring prints the response headers, including the Location line that holds the long address, without ever following it.

This is the right way round. Short links obscure the destination from a glance; they don't conceal it from anyone who checks. That's what makes short links safe to use as a reader — you can always find out where one goes — without making them a useful tool for hiding things. A service whose links can't be previewed is worth being suspicious of; a service whose links are routinely used for abuse gets its domain blocked by browsers and mail filters, and every honest link on it suffers. The guide to checking short links goes into the practical side.

Where QR codes fit#

A QR code is a short link printed as a pattern. The scanner reads the pattern, gets the URL, and the phone opens it — after which everything above applies: lookup, redirect, count. Encoding the short link rather than the destination is what makes a printed code editable: the pattern never changes, but where it goes can. The QR guide covers sizing and placement; the mechanism is the one you've just read.

In short#

Store a long address under a short key. Redirect requests for the key to the address. Note what you can about the request on the way through. Every URL shortener is that, and everything that distinguishes one from another is a decision layered on top: what it stores (your domain or theirs), what it counts (people or bots), what it shows on the way (nothing, or an ad), whether the destination can be changed later, and whether anyone can check where a link goes before they go there.

If you'd like to see the mechanism from the other side, shorten a link — a plain one needs no account — and then open its statistics page. The chart you'll see is the lookup, counted.

Related guides#

• How to shorten a URL: every method, one click to API
• Are short links safe? How to check one before you click
• Custom short link best practices: naming and organising
• Track marketing campaigns with short links (UTM guide)