Good point; for some reason I''d never fathomed of where a shortened link is going to take me.

I think that has to do with the level of personal trust for whom I''m clicking on a link in a tweet. Most of the time though I''ll be using Twitter via TweetDeck. Clicking the link will tell me the information I need to know about it.

The most important thing I believe from an untrusted source is showing how many clicks the link has had. Blind faith maybe, but it has had a lot of clicks, it must be safe.

Perhaps a good improvement is a temporary redirection page.

e.g.
In 10 seconds you''ll be redirected to http://thelongurlname.com. It has been viewed 600 times.
With a small site preview bigger than a thumbnail (a palm? hahaha).

This would provide transparency of where you''re going, and not be intrusive since it will redirect you without any prompting. Plus give you the chance to stop it.

I was half expecting to be Rickrolled when I clicked that link :)

URL shorteners are also a great way to hide tracking IDs from people.

3rd Party URL Shorteners are convenient, but besides the points above, what if the site changed policy, or goes away! Do you care, or are the encoded urls just a convenient throw-away reference? Or should these shortened urls be persisted some distance into the future? Just think of all the tweets archived by the Library of Congress; will all those urls be alive in 5, 10, 15 years? Maybe it doesn''t mater.

As the use of popular URL Shorteners continues to grow, at what point will they be comparable in length to some of the urls they are encoding?

My though is any content provider of significance should be providing their own URL Shortener (encoder). e.g. http://url.visitmix.com/sHq1 or http://url.visitmix.com/evlShrtnrs

One such project already exists on CodePlex that enables a site to implement it''s own url encoder: http://shrinkr.codeplex.com/

--Brian

The easiest solution would be to embed the shortening service into sites like Twitter and Facebook.

If Twitter handled the URL shortening, it would open up more options. They could provide a preview mouse-over or provide the url to devs via the api so apps could show a preview. Since bit.ly urls are usually 20 characters, Twitter could have a little javascript regex action going on that counts all urls in tweets as 20 characters, then save both the full and shortened url on the server side.

The other possibility is to create a standard for providing full urls. For example, if bit.ly/[linkid] redirects to the full url, make bit.ly/expand/[linkid] return an XML file with url details. If enough url shortening services supported this, it would be a great boon to developers.

I think showing clickthrough would be a very bad idea, actually. Let''s assume the link is malicious: People wouldn''t know it was a bad link until after clicking on it. Then the next visitors would see all those other clicks and click it as well (as Joshua said above "it has had a lot of clicks, it must be safe."), when in fact every one of those visitors had a bad experience after visiting the link. The cycle would continue, with each new visitor seeing an increased clickthrough count and feeling more confident about the safety of this malicious site.

Adding a delay to the redirect would likely annoy speedy Internet users. They would probably flock to a service which did not force a delay. I know I would.

Lastly, as nice as it is to implement one''s own shortener, any root domain longer than a few characters uses up valuable character real estate.

There doesn''t seem to be a simple solution. I''m wary of shortened links in many situations. And sometimes, I''m just impatient; I want to know what site the user is linking to without actually going there. I would be happy if the shortened links showed the full URL when hovered over. Anything more seems overkill to me - after all, the majority of the time we don''t need a lot of extra info when clicking on a full-sized URL (at least I don''t). How this would be implemented, however, I don''t know.

I agree with Brian''s point about content providers using their own branded URL shortener. This is an idea I first came across following @lisabarone on Twitter. I believe it was an article by Outspoken Media that discussed the idea that URL shorteners allowed for link hijacking on Twitter. For example:

@SomeGuy has a large following. Lots of people retweet him.

@Spammer know this and retweets @SomeGuy replacing his original bit.ly link with a substitute.

If website owners use their own domain for URL shortening it allows for branded links and it''s harder to hijack.

I currently use a WordPress plugin called Pretty Link Pro. It allows me the same link tracking that I would otherwise get through bit.ly and I find my links seem to retweet better.

Here is my shortened link to Pretty Link Pro: http://ajwood.com/plp

Actually there is a more sensible way to escape the evils of URL shorteners (which I think of as "the rust of the internet") - give webmasters the power to mint and advertise their own short links for all users. That way they can register a short domain (e.g. goo.gl), or for performance reasons use their existing domain (e.g. google.com), create a short link (e.g. http://goo.gl/6rRr) and then expose it to clients (e.g. browsers, twitter apps, etc.) via the HTTP Link: headers and/or HTML HEAD element using rel=shortlink. The resulting URL is more transparent and more importantly, generally as reliable as the content itself (CMS software like WordPress and Drupal 7 already support the rel=shortlink standard: http://code.google.com/p/shortlink/wiki/Specification).

Sam

I agree with Brian''s fear of the site''s policy changing or the site going away! (Should we relegate it to the W3 or the U.N.? No, just kidding...)

As for me, all I''d like to see in a URL shortener is a URL and, when available, a page title. Simplicity is best, and promotes speed.

Along that line, I''m VERY disappointed with bit.ly''s new "Fugu" setup (which at first I took as an insult). I don''t care for my links to be tracked, as they''re now doing.

A simple, clean, popup, with title and URL (a popup that works in ALL browsers, I might add), would be far superior.

Just as a note, I released a library that aggregated about 25 of the most popular URL shorteners into one easy to use API. Call a single method, pass in the name and required params of the desired shortener and you''re golden.

I haven''t added it yet, but I could just as easily add an expander to the library which would help with the opaque nature of short URLs. I''d love to get your feedback.

http://andymatthews.net/code/shrinkURL/

I also released an AIR application that piggybacks the library and lets you shorten any URL straight from your desktop.

http://andymatthews.net/code/Shrinkadoo/

All points you mentioned are valid. I think all of them can be fixed if you use your own url shortner (your own domain based). It should be a task of a day to create URL shorteners in .NET for an accomplished programmer.

I''ve not once thought about expanding a URL before clicking on it, especially on Twitter. Everyone I follow, I trust. Most of the time they''ll add context to the URL, which helps give me an idea of what I should expect to see. If they don''t, I just don''t click it. I get that this in no way validates what''s being linked to, but it has yet to fail me.

I''ve also enjoyed using bit.ly because I can collect a user''s data and see where they''re coming from, at what time, and who else has linked to that same page and not clicked on my bit.ly link – interesting stuff. I don''t see any major privacy concerns here.

As for a solution, Twitter Annotations are going to take care of (kill) URL shorteners on Twitter''s platform in a big hurry. Having developers be able to add their own metadata to a tweet is going to disrupt the URL shortening services, among other things.

This is why I built http://resolves.me - a simple service that gets info on the domain (PR and compete.com data) as well as giving the long url and html for those that want to look at that.

Interesting article, I have to say I agree with the issues regarding link rot.

This was highlighted last year when tr.im temporarily shut down and then reopened (and are subsequently due to shut down completely by the end of the year).

I''m with Sam Johnston. Go to the source of the issue and create a better end-result, rather than going to the end-result and trying to modify from there.

I would also say it''s a question of trust. And a question of good writing. This tweet is coming from XYZ Company and the reader already knows XYZ makes widgets. The tweet touts the new and improved purple widget. The reader knows where that link is going to take him.

As far as privacy goes, I don''t think you get a whole lot of information from just clikcing a link. Tell me if I''m wrong.

Hi,

I''ve been very interested in URL expanders for some time while creating a certain Twitter API enabled web app.

As a developer, the most useful thing I found for expanding was this:

http://longurl.org/api

This site can expand over a hundred URL shortening services AND gives you the developer access to the HTML title and meta tags too, so your users really know what they''re clicking.

This site is also good:

http://www.longurlplease.com/docs

It provides a neat JavaScript solution to expanding but it doesn''t provide titles or meta-info. Also can use any language able to parse JSON or XML to get your apps off the ground.

I gotta say, the comments here are hilarious. Part of the point is that there are too many different shorteners out there, but half of the comments are "Check out my url shortener un-shortening thingee!"

Now we have too many unshorteners to go along with too many shorteners.

I like url shortners. I use http://twig.mx all of the time. It is fast and reliable.