Microblogging has become a rage with the advent and success of Twitter which had a tagline – “What are you doing?”. Gradually it has become a platform for information sharing and communication. People have started sharing interesting and relevant links that they come across on the web which get shared again and again multiple times, disseminating information unimaginably fast to a large target audience. Microblogging imposes a limit on the number of characters in a message and hence the traditional URLs on the internet are very long and unsuitable for sharing over microblogging. So in came a series of URL shortening services that accepted a long, microblogging unfriendly URLs and gave out a URL much shorter in size which could be used on microblogging platforms and are print-friendly. What actually happens in the background is that, these URL shortening services create a short URL and map it to the long URL and whenever the short URL is referenced, the URL shortening services do a 301 redirect to the actual URL so that it opens.
There are a lot of aspects to this URL shortening services that most of the users don’t realize/are unaware of. One of the very important issues is that these shortened URLs are capable of breaking the internet. A shortened URL in a tweet for instance, may be a dangling link to nowhere if the corresponding URL shortening service purges its database or stops providing the service. A lot of popular URL shortening services are closing either because they can’t handle spammers’ abuse or they couldn’t make enough money out of the service to keep it running. Read about Link rot to get more details. This might also result in us losing the link that we wanted to share. The URL shortening services also provide client APIs to use their services which makes them more vulnerable to abuse and spamming.
Also shortened URLs hide the target link that we are trying to open, which could be a malicious one, which in its normal form most of us wouldn’t open. Nowadays the URL shortening services provide an option to preview the links before opening them, but there is a big question mark over how many users actually use that feature. Another significant issue is that the URL shortening services add an additional layer of indirection, an unreliable middleman, which adds to more DNS lookups and server hits and hence more traffic on the internet.
One of the possible ways to mitigate the evils of URL shortening is that every website could provide shortened URLs for its own content so that there is no need for a separate URL shortening service standing in the middle. This could reduce dangling links created due to issues with the third-party URL shortening service. For instance, every post on this blog has its own long URL and a corresponding short URL under the same domain. This makes sure that as long as the domain of this website is up, the shortened URLs too will be pointing to valid pages and hence lesser chances of link rot happening.
I got to know all these stuff while I was creating a URL shortening client application that uses the APIs of popular URL shortening services to create shortened URLs. I have decided to use URL shortening services very sparingly, only for ephemeral stuff or when there is a need to shorten a URL to meet the character limits of microblogging services. Hope this post will make the readers aware of the various aspects of URL shortening services so that they will use it very sparingly.