I’ve never gotten around to putting into words why exactly I so severely dislike services like TinyURL, Shurl, ln-s, etc. Let’s attempt to summarize a few key factors of what makes for a good (or, in Tim BL’s words, “cool”) URL:

1. Permanence: It doesn’t change.
2. Brevity: It isn’t too long.
3. Clarity: It is easy to recognize and remember.
4. Relevance: It expresses the scope and contents of the resource it refers to.

This, in theory, makes the following simple sequence of events possible:

1. A tells B a URL on the phone.
2. B has no time to look at it immediately, and jots it down on a note.
3. B finally decides to take a look, and remembers the context of why he wanted to look to begin with – even without checking out the resource it refers to.

The practice isn’t so great. Services such as TinyURL exist because people have found that many sites are severely lacking with the second point: their URLs are excessively long. Coupled with a frequent lack of clarity, this often makes it more practical to give someone a URL of the following form:

http://ln-s.net/14gA

, rather than the ‘proper’ variant of:

http://reviews.cnet.com/cell-phones/samsung-gleam-sch-u700/4505-6454_7-32643504.html?tag=cnetfd.mt

Now, I don’t mean to single out CNET, nor advertise for a Samsung/Verizon phone. But those two URLs – both referring to the same ultimate resource – demonstrate why the problem is there, but the solution lacking.

We’ll see in a few years how well the original URL does in terms of permanence, so let’s skip that one. For clarity, it actually scores a few points: the entire product name is within the URL (one can easily figure out “Samsung Gleam SCH-U700″ from samsung-gleam-sch-u700). Likewise, the scope and contents are clear as well: it’s a cell phone (/cell-phones) review (reviews.) from CNET (cnet.com). You can tell what this resource is about just by looking at the URL.

But sadly, it doesn’t do so well on brevity. It’s not just the 98 characters of length; it’s the excessive bits towards the end: the whole /4505-6454_7-32643504.html?tag=cnetfd.mt suffix is meaningless to a human and doesn’t belong there. It doesn’t matter whether CNET’s software insists on it; if it does, it’s simply broken. A URL is no place to reveal internals of a software’s architecture and data taxonomy.

Now, ln-s’s alternative. How short is it? 20 characters; a little over a fifth of the original. That’s pretty good. It may be permanent as well (though what’s the guarantee a service like this will continue to exist for years to come?). But on every single other point, it fails. It doesn’t tell you whether the actual resource you get to is a review, a picture, a software download, a tax report, malware or a shock site (contents), nor does it says anything about the originator, whom or which ln-s most likely has nothing to do with (scope). Finally, despite being significantly shorter, it is not that much more memorable: while you might remember the ln-s service if you use it often enough (or know people who do), the 14gA token of text is arbitrary and only maps back to the actual URL somewhere in a database table on ln-s’s servers. Which is cute, but doesn’t help you any.

Some services offer a compromise: TinyURL, for example, has a preview feature. You can enable this using cookies, or change any URL around to start with http://preview.tinyurl.com/ instead. This tells you what the actual URL is before redirecting to the URL, which is a great aid, and in my opinion quite recommendable.

Nonetheless, such services are broken. I find it quite unfortunate that Twitter, for one, completely relies on them, automatically shortening any URL you post to a TinyURL link.

It would be possible to compromise between the two extremes of brevity and clarity – which evidently are often conflictive. For example, a service could still append the domain to give some sense of scope, like a hypothetical http://ln-s.net/cnet.com/14gA. That would still be less than a third of the original URL length, and would already give you far more information. But it’s a subpar solution at best.

Those who run websites need to become more aware of making URLs that don’t suck. A session ID, a hash and other kinds of internals have no place in a URL – that includes suffixes like .php4 or .cgi. Not only do they needlessly lengthen it; they would also change whenever you switch software or make significant changes in the configuration. A URL is also not a file name; mapping it to one is in many cases not a good idea.

At the same time, those who use services like TinyURL should only do so when a URL is legitimately too long and hard to remember. Do you really have to put http://en.mystlore.com/wiki/Teledahn in a TinyURL service? No. So, please don’t.

These services aren’t all bad. But they’re overused by far – and, more often than not, solve the wrong problem.

For more, read Scott Rosenberg’s “Terror of tinyurl”, via reddit.