What Is a URL Shortener?

A URL shortener takes a long web address and returns a short one, built from the provider's own domain (bit.ly, tinyurl.com, t.co) followed by a short code. When someone opens that short link, the shortener's server looks up which original URL matches the code and redirects the browser there.

TinyURL, launched in 2002, was the first service to see wide adoption. Bit.ly followed in 2008 and became shorthand for the whole category, largely because Twitter capped messages at 140 characters for years, making it nearly impossible to share a long URL without shortening it first. That's why many people still say "bitly" for any shortener, the same way "Kleenex" gets used for any tissue.

Twitter, now X, runs its own internal shortener, t.co, which still rewrites every link posted on the platform, whether the poster wants that or not. Other well-known providers include TinyURL, Rebrandly and Ow.ly, each adding extras such as click statistics or custom branded domains.

Both options shorten a link, but they stop being interchangeable once that link needs to survive for years or carries a brand. The difference comes down to who controls the infrastructure underneath.

For a one-off social post, a third-party shortener is usually fine. For a link that will sit on a contract, an invoice, or a printed sign for years, a self-hosted redirect is the option that doesn't depend on another company staying in business.

The mechanism stays the same no matter which provider is behind it. Enter a long URL, and the service generates a short identifier, typically a 6 to 8 character string encoded in base62 (uppercase and lowercase letters plus digits), then stores that code alongside the original URL in its database.

When someone opens the short link, the browser sends a request to the shortener's server. That server looks up the matching original URL and returns an HTTP redirect response, almost always a 301 (permanent), though some providers use a 302 (temporary) so they can change the destination later or log each click in more detail before forwarding the visitor. The browser processes that response and makes a second request, this time to the real destination.

That second request is the technical crux of the whole setup. Every redirect adds an extra hop between the click and the final page, each with its own network latency. If a short link routes through more than one shortener before reaching its destination, say a bit.ly link that points to another shortener, the request turns into a chain of redirects, with one hop per link in that chain. Google recommends keeping such chains under three to five hops, even though Googlebot will follow up to ten.

Most providers also log every click (time, approximate location by IP, device type), which turns shorteners into campaign analytics tools as much as link compressors.

A URL shortener deserves attention today for two reasons: trust, and whether the link will still be there next year.

A shortened link hides the destination domain until the moment of the click. That's exactly the mechanism phishing campaigns exploit: a URL that would reveal a suspicious domain in plain text disappears behind bit.ly/xxxxx instead. Filtering systems that score a link's reputation based on the visible domain can't evaluate the real destination until they follow it, which weakens their defenses against shortened links. That's part of why the UK's National Cyber Security Centre (NCSC) tells organizations outright not to use URL shortening services in official communications.

On top of the trust risk sits an infrastructure risk. A shortened link is, technically, a redirect that depends on a third party keeping its service running indefinitely. When Google announced the shutdown of goo.gl in July 2024, more than 99% of its links had seen no activity in months, and those were exactly the ones that stopped working on August 25, 2025. One policy change at an outside provider can turn years of shared, published, or printed links into 404 errors overnight.

• If the link needs to last for years (contracts, packaging, signage), use your own domain with a 301 redirect on your own server instead of a third-party shortener.
• Before clicking an unfamiliar shortened link, hover over it or run it through a link expander to see the real destination first.
• Set up 301 redirects, not 302s, whenever the destination is final: browsers and search engines then treat the link as stable.
• Keep your own record of which short link maps to which original URL, rather than relying solely on the provider's dashboard to recover that data.
• For print or offline material, use a QR code that points straight to the final URL on your own domain, skipping the shortener entirely.
• Don't nest shorteners: shortening an already-short link just adds another redirect hop for no benefit.

• Using a free third-party shortener for links that need to work for years, with no backup plan if the provider closes or gets sold.
• Sending shortened links in official communications (banking, government, billing) without considering that the recipient can't verify the domain before clicking.
• Not checking where a shortened link received by SMS or email actually leads before forwarding or publishing it.
• Chaining several shortening services one after another, which only adds latency with no real benefit.
• Treating the shortener as the main analytics system without exporting or backing up click data outside its dashboard.