What to consider before shortening links

URL shorteners have upside, but they also raise issues around stability, privacy, and performance.

Chances are, you’re reading this article after clicking on a shortened link. And if, like many modern infovores, your online reading is driven by your social network rather than your feed reader, most of the pages you’ve visited today were mediated by a shortened link.

Link shorteners have become ubiquitous over the last few years, and they’re an increasingly important part of the social fabric of the web. But is that a good thing?

Below I explore some of the issues to be aware of, both as a user of link shortening services and a consumer of shortened links.

A brief history of link shorteners

Link shorteners have been around for a number of years. Wikipedia notes that the first link shortening service, TinyURL.com, launched in 2002. Back then the primary need for shortened links was avoiding line-wrapping issues, which could break long links in some email readers. In the years since, the web development community has recognized the utility of simple, readable URLs that are free of implementation cruft. URLs tend to be tidier than they once were. But the need for even shorter URLs has been driven by constrained user interfaces, either because of hardware issues or artificial constraints imposed by particular services. It’s no fun entering long URLs on a mobile device, and who wants to waste tweet space on URL characters?

The sharp rise in the number of shortening services — there are more than 180 services in this list — has been accompanied by a race to the bottom: who can generate the shortest URLs by creative use of domain name registration and by compressing URLs into as few characters as possible?

But while brevity might bring users to a service, it doesn’t necessarily bring revenue. Value-added mediation features, such as access to click-through statistics on individual URLs, has given services another dimension. Bit.ly’s live usage statistics, and its previously close relationship with Twitter, has made it beloved by many. The statistics Bit.ly and other services offer combine web analytics with your social media influence. They answer the question: How much traffic did you drive today?

Issues with URL shorteners

The issues surrounding URL shorteners all follow from the shorteners acting as an intermediary for destination websites.


As more web users find new content via shortened links, certain shorteners may emerge as considerable referral generators for some sites. If a service goes down, traffic could be temporarily blocked.

We don’t often think of the web as a long-term medium, but we should. There’s very little truly ephemeral content on the web anymore. The 301Works project from the Internet Archive is intended to address the issue of URL shortening services going permanently offline, providing an escrow service for link shorteners with the hope of preserving the integrity of more of the web. And, as recently illustrated by the take-down of vb.ly, there are more than just financial reasons why a site might go offline. Legal and ethical issues can arise, requiring developers to consider more than just what makes a short or cool-sounding domain name.

Some sites now offer their own domain-specific URL shorteners (e.g. youtu.be, goo.gl, t.co) that don’t suffer from the same issues. These are more likely to offer the same resilience and stability as the sites themselves. As a user, you’re better off turning to these services where available.


It’s hard to tell what’s at the end of a shortened link. From a user-interface point of view this can be frustrating. How many times have you followed a link in a tweet to find that it’s actually something you’ve already read? But that lack of visibility can be more than just frustrating, it’s also a possible vector for a phishing attack.

Not everyone pays attention to the URLs they’re visiting, and an unwary user can easily be taken advantage of through a seemingly innocuous shortened link. They’re a great way to hide a phishing site, exploit scripting vulnerabilities, or just avoid spam blocking. (Eric Hellman has created a nice list of “evil uses for URL shorteners.”)

If a URL shortener is hacked, as happened with cli.gs, then once innocuous links can suddenly become spam vectors.

Some services do apply a spam filter to shortened links, while others offer a preview mode or tools to increase visibility of the destination site. However, in the latter case, the user of the link usually has to take some additional action before following a link, making these less than ideal.

Again, domain-specific URL shorteners are likely to be more secure, if not more transparent than third-party services.


URL shorteners inevitably add overhead, requiring additional DNS lookups and HTTP requests. Domain-specific shorteners suffer in this regard just as much as third-party systems. Waiting for an additional web request can be particularly irritating on patchy mobile connections. For many users it won’t be clear where performance issues lie: Is it the link shortener or the target service that’s slow?

The role URL shorteners play in routing increasingly large chunks of Internet traffic makes their performance significant. It also makes them a highly visible target for denial of service attacks.

(Note: Here’s an interesting dashboard that provides some insight into up-time and performance for a selection of shortening services.)


An often overlooked issue with URL shorteners is that they have the ability to track the links you’re following across the web. Several services hand out tracking cookies as links are followed. It’s this facility that underpins the shorteners’ ability to offer usage statistics, although none yet offer the ability to track individual users. But, if you’re the type of person who is concerned about how your Internet usage is being recorded, then this is yet another avenue to consider.

Summing up

In all likelihood, URL shorteners are here to stay. As users and developers of web services we ought to understand when they are and aren’t useful, and what alternatives are available. Domain-specific shortening services avoid many of the issues identified here, but they don’t offer the same cross-site analytics that are the unique selling point of third-party services.

Disclosure: O’Reilly uses bit.ly Pro for its shortened domain, oreil.ly. O’Reilly AlphaTech Ventures (OATV) is also an investor in bit.ly.


tags: , ,
  • I don’t get this paragraph:

    “Some sites now offer their own domain-specific URL shorteners (e.g. youtu.be, goo.gl, t.co) that don’t suffer from the same issues. These are more likely to offer the same resilience and stability as the sites themselves. As a user, you’re better off turning to these services where available.”

    Actually I get it and I agree, but what throws me off is the the goo.gl and t.co examples. Seems to me, what you are saying is that if the shortener is run and operated by the same site as the actual destination of the then you’re probably ok (because of the shortener is dead, the actual site is probably dead too anyway). But goo.gl and t.co are no better than bit.ly in that respect since they are used for links to any site, not just to shorten google.com and twitter.com URLs. Unless you are implicitly saying that Google and Twitter will never go away. Which is a different argument. And one I would not agree with.

    Besides this, you’ve written a great round-up on shorterners, very clear and organized.

  • You’re right, URI shorteners are here to stay — unfortunately. And yeah, I’d trust goo.gl more than bit.ly. But I also can’t trust any URI shortener beyond the short distance I can throw it.

    As a matter of fact, each and every shortened URI is a sign of a major design flaw, brought to you by Twitter & Co. With maybe very few exceptions, none of the popular URI shorteners will live as long as the Internet. Therefore, they do break the Internet.

  • Great post, Leigh!

    I’d like to quibble with the assertion that TinyURL.com was the first link shortener. Those of us active in the DOI/Handle and PURL communities recognized in the late 1990’s that we could encapsulate ponderous, parameter-laden URLs with esp. PURLs. Of course this was also technically possible with HDLs, but was not nearly as easy.

    Sadly, my repeated efforts in the early 2000’s to convince certain parties to launch a HDL-based URL shortening service were met with non-comprehension. My argument is that conceptually, the notion of URL shortening and creating a Handle or DOI are the same; in fact a HDL-based short URL is potentially very powerful, because a ton of typed metadata can be persisted in the HDL record — not merely the (often) bogusly-long URL being shortened. This becomes very interested witht eh advent of Conneg-savvy HDL proxies…

    Clearly services like TinyURL.com and Shorl.com — the latter using the quirky, hash-like language “koremutake” — were more convenient alternatives and arguably were the first “pure” URL shorteners. Their failure lies with their overly-simplistic data models that prevent authentication, etc.

  • The come.to network was the first URL forwarding service I used. It was popular in the geocities and xoom communities 4-5 years before tinyurl appeared.