I hate TinyURL’s

You’ve probably seen these things… Instead of some ugly 5 long line link to an article that you have to cut and paste out of an email in 3 separate steps, you get something clean like http://tinyurl.com/9lcad.

Nice idea, bad execution. The problem of course, is that when I get one of these links I have absolutely no idea where I’m going to end up when I click on it. None. That’s a problem.

I want to know if I’m clicking on a link to a pdf or if I’m going to http://iloveraunchysex.com/fatties/. I want to know if I’m going to a site I trust, or something I’ve never seen before. I want to know if I’m wasting my time or not. With a tinyurl (or snipurl, or makeashorterlink, or shorl), I get none of these things. It’s a brick wall of obscurity hiding information from me.

I propose that they add the domain and possibly file type to the now-slightly-less-tiny url. So, it would look like http://tinyurl.com/nytimes/64lib or http://tinyurl.com/iloveraunchysex/avi/34dd.

A little bit of extra information goes a long way.

Update: In a bizarre occurrence of synchronicity, it turns out that someone else decided to implement this exact idea yesterday. Crazy. I hope he goes ahead and adds the file type suggestion too.

Update 2: In addition to Andrew’s nice burl site, another Yahoo! has taken my suggestions as well as some neat parsing of the page title and built http://www.url.vg.

Update 3: 1/3/2006 Looks like a friend of a Yahoo! has built http://urlx.org/. Probably the nicest implementation yet. No one has yet implemented my file extension idea though…

Update 4: 1/14/2007 I like this approach much more: http://giganticurl.com

16 Responses to “I hate TinyURL’s”

  1. Dan McKinley Says:

    http://tinyurl.com/2oovs

  2. Udi Says:

    Exactly.

  3. Andrew Ferguson Says:

    I spent the better part of today thinking about your suggestion and the different aspect surrounding the implementation. Here’s the problem I came up with. The point of adding the file extension is to identify what is on the other end. However, there is no way to reliably determine what is at the other end. If someone links to an image, they could link directly to that image, or they could link to a page that has the image in it. Adding the file extension to the link only helps in one of those cases even though they both produce the same result, for the most part.

    Hopefully this makes some sense. I will keep the idea in the back of my mind though. And if you have any more ideas, please feel more than welcome to pass them on!

  4. Udi Says:

    Hey Andrew, thanks for commenting. Even if it only helps in one of those cases, is that not still more helpful than doing nothing? I think the filetype is pretty much the only other useful piece of metadata that you can get from a url. With the domain and filetype in hand, you know quite a bit about what you might be getting yourself into. The idea being that it’s really annoying to unexpectedly open a pdf or movie file because it leads to other programs opening and all that. It would be nice to know a bit more beforehand. Just my 2 cents, but thanks for writing burl, you beat me by one day, hehe.

  5. Andrew Ferguson Says:

    Here’s the thing though: if you start putting in filetype data, then you’ve set a precedent. If I give you a link to http://burl.fergcorp.com/microsoft/38jf9 and it takes you took a web page, then you would expect that links similar to that one would provide similar type of data. This is reinforced by the fact that I send you another link to, say, http://burl.fergcorp.com/msn/jpeg/dj3k0. This time it’s a picture. You would expect that links that follow that format will take you to some sort of picture. So when I send you to http://burl.fergcorp.com/google/dkj39 and it links to Google Image search for something just God aweful, you are suprised because there wasn’t a jpeg in the URL. Trust is loss and the system is broken.

    I know that’s not the best example, but it’s the best I could come up with.

    The other issue is implementation. How do you determine what the true filetype is? Many programs/browsers ignore filetypes and depend on MIME types instead. So the link I create could point to a URL that ends in a .jpg, even though it’s a PDF file. So now to prevent abuse, you have to load each file and determine its MIME type. Bandwidth is now soaring through the roof.

    In other news, I’ve released the BURL source code under a GNU GPL License. So feel free to go download and tweak it to your hearts desire. If you need any help, let me know!

  6. Udi Says:

    I think you’re overthinking this Andrew. If I get a regular link with a file extension in it, it still has all these issues that you’re describing. But, I’m used to that already and removing the extension simply means less information for me to work with.

  7. Scott Lawton (Blogcosm) Says:

    FWIW, I’ll vote with Udi. But, instead of a path, just echo the URL’s extension in the not-quite-so-tiny URL, e.g. http://burl.fergcorp.com/msn/dj3k0.jpg

    The URL service doesn’t promise anything except that it shrunk the URL and preserved the extension (if any).

  8. TerminalDigit Says:

    I realize you wrote this 2 years ago, but just for people who arrive here in the future, I’d like to point out that adding the “preview” subdomain in front of the tinyurl will reveal the full url that you’ll be forwarded to. Using your example, this would look like http://preview.tinyurl.com/9lcad

    Optionally, you can have TinyURL set a cookie that will always take you to one of these preview pages first.

  9. Udi Says:

    The preview is a nice feature, but having to go through an intermediary page is still very cumbersome. I still see no reason why we can’t still put the domain and extension into the short url.

  10. rnc Says:

    try http://decenturl.com

  11. Mostly Muppet Dot Com Says:

    The Problem with Permalinks…

    I’ve been thinking for quite some time about changing the URL structure at Mostly Muppet Dot Com to be a little more human-friendly. You know, taking out all the “archives” and date-string bullshit and just getting to domain-slash-po…

  12. dan Says:

    I found that http://www.redirectrevealer.com can unmask these urls and return the final destination url so you see exactly where you are going before you click the link.

  13. epot’s blog » Blog Archive » The problem with TinyURL … Says:

    […] tell us they may report your activity to some “agencies” … In addition to the reasons why Udi hates TinyURLs, I wonder how is stored your URLs. Well, it’s not exactly “how?” but “with […]

  14. epot’s blog » Blog Archive » The “problem with TinyURL” is (partially) solved Says:

    […] next step would be an implementation of some “intelligence” in these short URLs (see Udi’s post). And since I never have time (or less and less), I’m a bit sad not to have that time to code […]

  15. werun Says:

    i had also been facing problem with tinyurl.com. So i was looking for an alternative. I found this one – http://turl.us . turl.us is much better than tinyurl.com. I now use http://turl.us. It provides complete stats and bulk submission and lots more

  16. JF Says:

    I just hate the word ‘URL’ and can’t stand the use, utterance or propagation of such a nerdy acronym – Universal Resource Locater. The words site, address, or simply website is far more intuitive and a MUCH better way of communicating. Earl – give me a fucking break!