How URL Shorteners Actually Work (and What They Can See About You)

A shortened link looks like magic — a random handful of characters somehow leads to a specific, often much longer, destination. Underneath, it's one of the simpler mechanisms on the web: a lookup table and a redirect.

The mechanism: a lookup, then a redirect

When a short link is created, the service stores a row mapping a short code (abc123) to a destination URL, in an ordinary database. When someone visits the short link, the server looks up that code, finds the destination, and sends back an HTTP redirect response telling the browser to go there instead. The short code itself carries no information about the destination — it's an arbitrary key, the same way a phone book entry's page number tells you nothing about the person's address until you look it up.

301 vs. 302: a choice with real consequences

Redirects come in two common flavors, and the choice matters more than it looks:

• 301 (permanent) tells browsers and search engines "this redirect is permanent — remember it and go straight to the destination next time, and give the destination page's search rankings credit instead of the short link's." Browsers and crawlers may cache a 301 aggressively.
• 302 (temporary/found) says "redirect for now, but check again next time" — nothing gets cached long-term, and search engines don't transfer ranking signals to the destination.

A URL shortener that wants to keep tracking every single click (not just the first one from a given browser) needs to use a 302, not a 301 — a cached 301 means the browser skips the shortener entirely on repeat visits, which also means the shortener never even sees, let alone can log, those later clicks.

What a shortener can track — and what most don't

Because every click physically has to pass through the shortener's server before being redirected, that server is in a position to log quite a lot per click: IP address, timestamp, user agent, referrer (what page linked to the short URL), and sometimes location inferred from IP. Whether a given shortener actually stores all of that, versus just an aggregate click count, depends entirely on that service's own implementation — the mechanism makes detailed tracking possible, but doesn't make it universal.

Spellkit's URL Shortener keeps this deliberately minimal: it stores the original URL, the generated short link, and a simple click counter — not per-click IP logs, device fingerprints, or referrer tracking. Standard web-server access logs (IP, timestamp) are recorded the same way for any request to the site, same as they would be for any page view, and short links expire automatically after 30 days.

Why this matters before you share a link

Because a shortener sits in the middle of every click, sharing a shortened link means trusting whichever service generated it with knowing (at minimum) that the click happened, and depending on the service, potentially who clicked and from where. This is also why security-conscious contexts (and Spellkit's own implementation) check a submitted destination URL against a malware/phishing database before creating the link — a shortened link hides the real destination from the person clicking it until they arrive, which is exactly the property that also makes shortened links a convenient vector for disguising a malicious destination.

Custom slugs and branded links

Beyond the basic redirect mechanism, most shorteners let you pick a custom slug (/r/my-launch instead of a random string) — purely cosmetic from the redirect's perspective, but useful for a link that'll appear in print, a presentation, or anywhere a random string of characters would look out of place.

Spellkit's URL Shortener supports a custom slug, an Open Graph preview title/description so the link shows a proper card on social media, and works with no signup — paste a URL and get a short one back.