The Case Against URL Shorteners

Personally I hate URL shorteners and it is not because they’re are so many of them…

2 Short.Url (2su.de), 2Zeus, 3.ly, 9mp, a.gd, abbr, arm.in, a.nf, bit.ly, bloat.me, Buk.me, BurnURL, Chilp.it, cli.gs, clk.my, Clop.in, DiggBar, ff.im, Fly2.ws, fon.gs, Foxy URL, FWD4.me, g4.ms, gl.am, Good.ly, Gurl.es, hex.io, Hurl.no, idek.net, irt.me, is.gd, J2j.de, kissa.be!, Kisa.Ch, kl.am, krz.ch, Kore.us, Kots.Nu, ktzros, Lincr, LinksPreadeR (l.pr), LinxFix, LNK.by, lt.tl, lurl.no, Metamark (xrl.us), migre.me, micURL, min2me, MinURL, Moourl, MyURL.in, nd url, Pendek.in, Pic.gd, PiURL, Plurl, pnt.me, POPrl, pt2.me, Puke.It, qr.cx, Qurl, qux.in, r.im, RDE.me, redir.ec, RIMS, rnk.me, RubyURL, Safe.mn, Sai.ly, SFU.ca, shorl, Short.ie, short.to, shortn.me, Shrtn, Shw.me, Smallr.net, SMFU, Snipie, SnipURL (sn.im), snkr.me, song.ly, srnk.net, StumbleUpon (su.pr), TightURL, TimesURL, tini.us, Tiny.cc, TinyURL, to.ly, to.vg, tr.im, tra.kz, tsort.us, tweet.me, Tweetburner (twurl.nl), Twip.us, Twirl.at, twtr.us (tw6.us), u.nu, UiopMe, ur.ly, URL.AG, URL.ie, URL (un)faker, urlBorg, urlShort (ooqx.com), urlShort (u.mavrev.com), urlzen, Virl, vl.am, VTC, XORTR (xrt.me), XR.com, xrl.in, X.vu, xxsurl.deZ.PE, Zi.pe, ZipMyURL, ZZ.GD

…and those are only the one’s which I have recently interacted with.

I hate the fact that I am forced to use them – with the main ones that I am forced to use being ff.im and bit.ly although ff.im links are only generated when sending FriendFeed data to Twitter so that doesn’t really bother me.

For example, if I go to Twitter and post a link it is automatically converted to a bit.ly link don’t get me wrong bit.ly is a really cool service especially the  “+” feature and the same happens when I click on a link from Twitter it is generally a bit.ly link (unless someone created it manually or used a service such as awe.sm like Techcrunch do) which means that we are basically adding an extra layer to the system.

However this isn’t the major problem with URL Shorteners.

Let me explain.

The Internet was designed in a way which meant that there wasn’t a single point of failure which could easily break large parts of the web. URL shorteners can cause this single point of failure because, a regular hyperlink implicates a browser, its DNS resolver and the publisher’s DNS server and website whilst a URL shortener adds an additional layer which acts like a third DNS resolver and if a problem occurs with the URL shortener then you can’t access the ‘real’ hyperlink which causes a single point of failure.

Additionally this extra layer means that it’s going to take time to get you to the link due to additional DNS lookups and server hits.

Expanding on this single point of failure theme, URL shorteners become middlemen sitting between the link and its original destination. This is one of my biggest concerns which I have previously expressed and which has been highlighted recently by the media with the fact that Tr.im decided it was going to close down although it has since decided to go “open-source” and remain open as the third-party could decide that a link which you shorten violates its Terms Of Service and delete it. Moreover, the URL shortener which is now the key to getting to the original link could experience downtimeaccidentally erase the database, forget to renew its domain, get hacked, disappear or change the way its url shortener works which means instead of sending you directly to the original link it sends you to a page on their site which contains the original link on.

Consequently, there is the usability aspect of using a URL Shortener which is highlighted on Twitter.com itself as you can’t tell where the link will take you (although you can tell on Twitter Search). However, FriendFeed does expand the url which helps to prevent phishing but many sites are like Twitter and do not expand the shortened URL.

13 Responses to “The Case Against URL Shorteners”

  1. Yet another example of, The Law!!!™ coming into play…. Pretty soon, all this stuff will be documented, and then it will no longer matter, however, there will probably still be unintended consequences to deal with….

  2. [...] the original: The Case Against URL Shorteners « Profit Baron This entry is filed under Web, url. You can follow any responses to this entry through the RSS [...]

  3. Bertil Hatt says:

    Any site with the importance of Twitter shouldn’t fail without making a large chunk of the web fail — but you are right, the resilience of the web structure demands that a large service isn’t dependant on smaller ones with little differentiability. Twitter should keep at least a copy of full URLs, and summon the database when the service goes down.

  4. [...] This post was Twitted by SexySEO [...]

  5. Jeremy says:

    SFU.ca isn’t a URL shortener — it’s Simon Fraser University.

  6. Eric says:

    Your point is well taken, but isn’t Twitter itself kind of the biggest “single point of failure”?

  7. Sam Johnston says:

    Well the good news is that the rel=shortlink standard is rapidly gaining momentum. With last week’s WordPress.com announcement there’s now well over 100 million pages advertising short links (also PHP.net, Ars Technica, etc.)

    Sam

  8. Floost says:

    I really like your blog and i respect your work. I’ll be a frequent visitor.

  9. Kouba says:

    I liked it. So much useful material. I read with great interest.

  10. [...] Profit Baron New Design Coming Soon! « The Case Against URL Shorteners [...]

  11. Short URL says:

    Thank You For keeping it on target!

    Best Regards

  12. Hey!
    Personally I don’t have any issue. But I have experienced that these URL shorteners cause more disturbances ,errors, faulty or malware links that it is way too much of a trouble compared to advantages.

  13. If it helps, I’ve written a URL UN-shortening web site, complete with API:

    http://unfwd4.me

    Suggest a firefox addon or similar, so when you hover over any short url it could api call the long url behind it?

Leave a Reply