URL shortening services rely on three core technical components: short code generation, database storage, and HTTP redirection. This article explains how short URLs are generated and how users are forwarded to the original destination, with actual HTTP response examples.
When you submit a long URL, the service generates a unique short code. Several approaches exist for this step. These include random alphanumeric string generation, extracting a portion of a hash (such as SHA-256) from the original URL, and encoding sequential IDs in base-62 format. Base-62 encoding uses 62 characters: digits 0-9 (10), lowercase a-z (26), and uppercase A-Z (26). For example, the sequential number 100000 converts to "q0U" in base-62 (just 3 characters). A 6-character code provides 62^6 = approximately 56.8 billion possible combinations, a number that makes it hard to run out of codes even for large-scale services. Hash-based methods can generate the same code for the same URL, which is useful for deduplication, but require collision handling when different URLs produce the same hash prefix. Sequential methods avoid collisions entirely but produce predictable codes, requiring security considerations to prevent enumeration attacks.
The mapping between the short code and the original URL is stored in a database. Some services use high-performance NoSQL databases like DynamoDB, because URL shorteners are read-heavy workloads. A caching layer using Redis or Memcached can also improve response times. Some large-scale services place a CDN like CloudFront in front of the origin server, caching redirect responses at edge locations and returning redirects from locations close to users. However, when using CDN caching with 301 redirects, the TTL (cache duration) needs attention. If you change the destination URL while the cache remains, users will continue to be forwarded to the old URL until the cache expires. This is a tradeoff between performance and flexibility.
When a user clicks a shortened URL, the server performs an HTTP redirect. The actual redirect response consists of HTTP headers like: "HTTP/1.1 301 Moved Permanently", "Location: https://example.com/very/long/original-page?utm_source=campaign", "Cache-Control: max-age=86400", "Content-Length: 0". The browser reads the Location header and automatically navigates to the specified URL. There are two primary redirect types: 301 (permanent) and 302 (temporary). While a 301 redirect stays cached in the browser, subsequent visits are faster, but they skip the server during that time, so the server does not see those repeat clicks. A 302 redirect passes every click through the server, which makes clicks easier to count. Some URL shortening services use 302 redirects to prioritize tracking accuracy.
You can verify redirect behavior directly using the curl command in your terminal. Running "curl -v -L https://short.url/abc" displays the response headers including the HTTP status code and Location header. The "-I" flag retrieves headers only, which is convenient for inspecting redirect chains.
The complete flow from DNS resolution to redirect completion works as follows. The browser resolves the short URL domain via DNS, obtaining the server's IP address. It then establishes an HTTPS connection through a TLS handshake and sends an HTTP GET request to the server. The server looks up the short code in the database or cache to retrieve the original URL, then responds with a redirect status code and the original URL in the Location header. The browser navigates to the destination through a similar DNS resolution and connection process. Using a CDN can help shorten the time from initial DNS resolution to receiving the redirect response.
Choosing between redirect types involves a tradeoff based on your use case. For permanent links where SEO matters, 301 redirects are preferred. With a 301 redirect, link juice (PageRank value) is said to pass to the redirect destination. For marketing use cases where click tracking accuracy is the priority, 302 redirects are suitable. Some services offer the option to select the redirect type on a per-link basis.