A URL shortener maps a long URL to a short code, stores that mapping, and redirects anyone who visits the short URL to the original. The concept is trivial. The implementation has interesting engineering decisions at every step.
The core data model
short_code -> original_url
That is the entire data model. A key-value store. A hash map. A database table with two columns. The engineering challenges are in generating the short code, handling collisions, and scaling the redirect.
Generating short codes
The short code needs to be short (obviously), unique, and ideally URL-safe. The standard approach uses base62 encoding (a-z, A-Z, 0-9), which gives 62 possible characters per position.
A 6-character base62 code has 62^6 = 56.8 billion possible values. A 7-character code has 3.5 trillion. For most use cases, 6 characters is more than sufficient.
Method 1: Auto-incrementing ID. Assign each URL an incrementing integer ID (1, 2, 3...) and base62-encode it. ID 1 becomes "1", ID 62 becomes "10", ID 1000000 becomes "4c92". Pros: no collisions, simple. Cons: codes are predictable (sequential), revealing your total URL count.
Method 2: Hash-based. Hash the URL (MD5, SHA-256), take the first N characters, and base62-encode them. Pros: same URL always gets the same code. Cons: collisions are possible and must be handled (check if code exists, append a character if so).
Method 3: Random generation. Generate a random 6-character base62 string, check if it exists, use it if not. Pros: unpredictable codes. Cons: collision checking required, probabilistically slower as the database fills.
function generateCode(length = 6) {
const chars = 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789';
let code = '';
for (let i = 0; i < length; i++) {
code += chars[Math.floor(Math.random() * chars.length)];
}
return code;
}
The redirect: 301 vs. 302
When someone visits the short URL, the server looks up the code and returns an HTTP redirect to the original URL. The choice between 301 (permanent redirect) and 302 (temporary redirect) has significant implications.
301 (Permanent): Browsers cache this redirect. Subsequent visits skip the shortener server entirely and go directly to the target. Pros: faster for the user, less load on your server. Cons: you lose analytics (visits are not hitting your server), and you cannot update where the short URL points.
302 (Temporary): Browsers do not cache. Every visit hits your server first. Pros: full analytics, ability to update the target URL later. Cons: slightly slower, higher server load.
Most URL shorteners use 302 because the analytics are the primary value proposition. The short URL itself is just a vehicle for tracking clicks.
Analytics and the real product
URL shorteners make money from analytics, not from the shortening. When a click passes through the shortener, you capture:
- Timestamp
- IP address (geolocation)
- User-Agent (browser, OS, device type)
- Referrer (where the click came from)
- Click count over time
This data tells you when, where, how, and how often people click your links. For marketing campaigns, this is essential. A social media post generates clicks, and the short URL tells you exactly which post drove which traffic.
Privacy and security concerns
Short URLs obscure the destination. You cannot tell from sho.rt/x7Kq9p whether it leads to a legitimate website or a phishing page. This is why many security-conscious organizations block or warn on short URL clicks.
The mitigation is preview pages. Adding a + to a bit.ly URL shows the destination without redirecting. This lets users verify the target before clicking.
I built a URL shortener at zovo.one/free-tools/url-shortener that generates short links with optional custom codes, click tracking, and destination preview. It is a straightforward tool for creating shareable short URLs without depending on third-party shortening services.
I'm Michael Lip. I build free developer tools at zovo.one. 500+ tools, all private, all free.
Top comments (0)