What it is

A URL shortener takes a long web address and turns it into a much shorter one that redirects to the original. A lengthy link like https://example.com/articles/2026/tech/very-long-title?ref=news becomes something like bit.ly/3xY9kZq - the same destination, a fraction of the characters.

The short link is not a copy of the page or a new address for it. It is a stand-in whose only job is to point at the real one. To understand exactly what is being shortened, the anatomy of a URL is the companion to this article - a shortener replaces the whole thing with a tiny host plus a short path.

How it works

The mechanism has two halves. When you create a short link, the service stores a mapping - a row in a database pairing the short code (3xY9kZq) with the original long URL. That is the entire data model: a lookup table from code to destination.

When someone clicks the short link, the service looks up the code and sends the browser an HTTP redirect - a response that says "the thing you want is actually over there." The redirect carries a status code, and which one matters:

  • 301 (permanent) - tells browsers and crawlers the move is permanent. It can be cached and, for search, passes the destination's ranking signals through. The default for a link meant to last.
  • 302 (temporary) - tells them the redirect may change. It is not cached the same way, so every click hits the service - which is exactly what you want if you are counting clicks.
1 · GET /3xY9kZq 2 · 301 → Location 3 · GET long URL Browser you click Shortener code → URL Browser follows 301 Destination the real page
A short link is a database lookup wrapped in a redirect - the browser makes two requests, one to the shortener and one to the real destination it is sent to.

So a shortener is a database lookup wrapped in a redirect. The tradeoff between 301 and 302 is really a choice between letting the browser cache the hop (fast, SEO-friendly) or forcing every click through your server (measurable). Analytics-focused services lean toward 302 for that reason.

Why people use them

Short links solve a few unrelated problems at once:

  • Sharing in tight spaces. Social posts, printed materials, and QR codes all get easier when the link is short - a giant URL is hard to type, ugly on a slide, and dense as a QR code.
  • Analytics. Because every click can pass through the service, many shorteners report how many clicks a link got, where visitors came from, and what devices they used - overlapping with the UTM tracking covered elsewhere in the series.
  • Branded slugs. Some services let you replace the random characters with a custom, readable code - yourbrand.link/sale instead of bit.ly/3xY9kZq - which reads as trustworthy and reinforces the brand.

Popular services include Bitly, TinyURL, and Rebrandly. They differ mostly in the analytics and branding features layered on top of the same redirect core.

How you would build one

Building a shortener is a classic systems-design exercise, because the simple idea hides real challenges at scale. The central one: how do you generate a short, unique code for every link? The common approach is base-62 encoding - representing a number in the 62 characters a-z, A-Z, 0-9, which packs far more into each character than base-10:

const ALPHABET =
  "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";

// turn an auto-incrementing database id into a short code
function encode(id) {
  let code = "";
  do {
    code = ALPHABET[id % 62] + code;
    id = Math.floor(id / 62);
  } while (id > 0);
  return code;
}

encode(1);        // "b"
encode(125000);   // "GGi" - 3 chars; 6 chars would cover billions of links

Take an incrementing ID from the database, base-62 encode it, and you get a unique code for free - no collisions, because every ID is unique. (The alternative is hashing the long URL and taking the first few characters, which needs collision handling.) The rest of the problem is operational: serving billions of redirects with low latency, and caching the hottest links in memory so a popular link never touches the database. It is a favorite interview question precisely because it starts trivial and gets deep.

Two real risks

Two downsides are worth knowing before you rely on one:

  • Hidden destination. A short link does not show where it goes, so a reader cannot tell a real link from a malicious one. That opacity is exploited for phishing - the reason many people paste short links into a preview/expander before clicking.
  • Link rot. The short link only works as long as the service runs. If the shortener shuts down, every link it ever created breaks at once - the redirect has nowhere to send you. A long URL, by contrast, keeps working as long as the destination does.

There is also a smaller cost: every short link adds a redirect hop, which is one more lookup of latency and one more point that can fail. For links meant to last - documentation, citations, anything archival - the honest advice is often to use the real URL and accept the length.

Shorteners, tags, and search

Shorteners sit right where two other articles in the series meet. They are frequently used to wrap UTM-tagged campaign links - the long, parameter-heavy URLs that tracking produces are exactly the ones too ugly to share raw, so the shortener hides the machinery and counts the clicks in one move.

And they lean on the redirect behavior that matters for ranking: a 301 passes the destination's authority through, so a shortened link can be shared widely without the short domain absorbing the credit. Understand the URL and the redirect, and a shortener stops being magic - it is a lookup table and a well-chosen status code.

References