On URL readability

Yesterday, I was watching some season 6 episodes of Futurama (btw, this is their best season ever!) and I noticed the URLs in the website I was in (let’s call it foo.com). They were like:


I thought to myself “hey, this looks very clean and readable”. And then I noticed that it only has 1 less character than its non-rewritten counterpart:


However, I’m pretty sure you agree that the second one is much harder to read. I asked for opinions on twitter, and got many interesting replies. Apart from the ones that completely missed the point, these were the core explanations:

  • = and especially & are more complex and look more like letters, so our brain has trouble tuning them out (@feather @robert_tilt @rexxars @mrtazz @manchurian)
  • Slashes have more whitespace around them, so they are less obtrusive (@feather @stevelove @kenny1987 @janl)
  • They’re all visual noise, but we always have slashes in a URL, so using the slash to separate keys and values as well only introduces 1 separator instead of 3 (@bugster @craigpatik @nyaray)
  • Slashes imply hierarchy, which our brains process easier than key-value pairs. Key-value pairs could be in any order, paths have a specified order. (@sggottlieb @edwelker @stevenhay @jwasjsberg @stazybohorn)
  • Ampersands and equal signs are harder to type than slashes. They’re both in the top row and ampersands even need the Shift key as well. (@feather)
  • Ampersands and equal signs have semantic meaning in our minds, whereas slashes not as much (@snadon)
Regarding hierarchy and RESTful design, the first example isn’t exactly correct. If it was hierarchical, it should be foo.com/futurama/seasons/6/episodes/9. As it currently stands, it’s key-value pairs, masquerading as hierarchical. However, it still reads better.
So I’m leaning towards the first three explanations, although I think all of them have a grain of truth. Which makes me wonder: Did we choose the wrong characters for our protocol? Could we have saved ourselves the hassle and performance overhead of URL rewriting if we were a bit more careful in choosing the separators back then?
Also, some food for thought: Where do you think the following URLs stand in the legibility scale?
http : //foo.com/futurama-season-6-episode-9  (suggested by Ben Alman)
Do you think there are there any explanations that I missed?
  • I don’t know why you’d want either slashes or ampersands. Why not this?

    • Added to the post. I personally don’t find it more legible than the slashes tho.

    • I’d want slashes for the same reason Pewpewarrows: It implies url hack-ability. Slashes are logical folder separators, so if you delete the last segment, the assumption is you go “up one folder”. If the name had hyphens, I would think it’s a hard-coded file and I wouldn’t touch it

      • There’s no reason you couldn’t hack the hyphens:

        http : // foo.com / futurama-season-6-episode-9
        http : // foo.com / futurama-season-6
        http : // foo.com / futurama

        Also, these (while not hackable) are more human readable than their “hackable” counterparts, which are singular, not plural:

        http : // foo.com / futurama-season-6-episodes
        http : // foo.com / futurama-seasons

        Most people aren’t engineers. They don’t know or care about directories, and thus don’t know or care about what a slash (/) in a path signifies. They use their operating system’s built-in search to find files, which typically indexes the entire hard drive. They use tags and only the most basic hierarchy (categories) as a means of cataloguing and finding their documents, photos, content on websites, etc.

        I used to “hack” URLs all the time with the Google Toolbar, then later, my Up! bookmarklet, but I seldom need or want to do this anymore.

        • Regarding their “hackable counterparts”: I’ve mentioned this in my post. They just did hierarchy wrong. It should be seasons/6/episodes/9

        • But it’s not “seasons 6, episodes 9,” it’s “season 6, episode 9.” Remember, we’re talking about readability, which includes human readability.

        • Depends on whether you want it to be readable as a hierarchy or as key-value pairs. You wouldn’t have a folder called “season”. It would be “seasons”

        • It wouldn’t be tricky on the back end to detect if the URL contains a singular value (e.g. episode) with no following ID (9) and to redirect the request to the plural (episodes) instead.

  • Matt Wilcox

    Legibility is one aspect, but legible does not mean understandable. The first is not only easier to read optically, but simpler to *understand* too. And that’s what makes a big difference. In the non re-written example we must work out that ? & and = are all “meaningless”. In the second we can just ignore the / from a syntactic standpoint. The slash becomes a space, and the url “reads” instead of having to be deciphered.

  • @ben – directory listings.

  • Pascal Precht

    Very interesting thoughts!  In my opinion, slashes are the best way too. Just because of this hierarchic thinking and the fact, that we’re using slashes for naming our files.

  • Juanjo

    I’d go for /futurama/season:6/ or /futurama/season-6/, as in grouping in between the slashes what “belongs together”.

  • Anonymous

    i think it should be slashes all the way. anything else is just noisy and breaks the flow of reading

  • A common shorthand is s6e9. so, a url like /futurama/s6e9 would be nice and succinct.

  • For me, the slashes always implied url hack-ability.  In your example, if I take: http://foo.com/futurama/season/6/episode/9

    … and cut off the “9” at the end, I should be taken to a URL that shows me a list of all episodes in season 6. If I cut off “episode”, I should see general information about season 6, which may or may not also conveniently list episodes from it. So on, and so forth.

    With any of the other possibilities, including our current one with ?&=, there’s no clean way to cut back on the URL to access broader portions of the site.

    • Same here, but I don’t think that’s true for non-geeks.

      • True, though I have to wonder how much clean URLs matters to non-geeks. I’m sure on some level the general user base must notice it, but to what extent?

      • That’s true for everyone who can tap on the title with two fingers (what, right clicks are so 2000) in Safari! http://mfwb.us/okLK

  • I think the Slash is a very good url seperator, the colon and the equal sign are too small to visually see the seperator and though we are not used to look for this one. Or vice versa, we are used to look for the slash.

    As for season VS seasons, I think this is a site-wide setting. Either stick with the singular or the plural, similar to ERM design. The slash operator visually explains the hierarchy seperation.

    P.S. On german keyboard, the Slash is on shift+7.

  • Anonymous

    I would set it up as:

    …/futurama/season-6/episode-9/ which leaves the ability to drop sections to:

    …/futurama/season-6/ (list all episodes in season 6)

    • KMB

      I would go the same way. The slashes imply entities and I think a lot of web-users are “trained” because of directory-structures to distinguish those. The URL-rewrite-frenzy of the last years made equal-signs so passé and the colon is hardly used in an URL, that the dash is the most reasonable choice.

    • Was about to suggest the same thing as an alternative.

    • Anonymous

      For a little more SEO flavor you could go with:


      It is easy to find the episode number since it will always be the 2nd element in the episode slug.

  • Eddie Welker

    Some of this is dictated by historical factors.

    Filesystems were added to Unix in the 60’s, and the original FTP spec
    (http://tools.ietf.org/html/rfc114, 1971) included them as well.  So by
    the time TBL got around to writing about URIs in 1994
    (http://www.ietf.org/rfc/rfc1630) though I don’t have any evidence, I
    believe that the ‘/’ character to delimit path segments was already so
    well established, that they didn’t have many design choices. What they
    did define was that they wanted URIs so they could be hand-written (so
    white-space characters should be omitted), as well as emailed (so
    anything that would be stripped in a 7-bit SMTP message should also be
    left out).  Thus they settled on their subset of characters for use in
    URLs.  I don’t know how they designated certain characters for other
    parts of the URI, but I’m sure you could find with some digging.  As for how ‘/’ came to mean path at the time of, or before Unix/FTP, that would take a lot of digging.  🙂

    As for “key-value pairs, masquerading as hierarchical,” in
    scheme/path/seasons/6/episodes/9, I don’t think there’s a fine line
    there… I believe that it’s both a key-value pair and a hierarchical
    representation… I don’t think the two are mutually exclusive.  I believe your real question is… “what are the
    best practices for a key-value mapping to a hierarchical structure, from
    the user perspective?”

    Simply put:
    For the “legibility” of the url (which I define as usability in reading the text), that’s probably best decided by character shape (/ vs . vs : vs -, etc).

    For comprehension (usability in interpreting text as a hierarchy), and assuming the concept of a hierarchy is universal, that probably has more to do with language and writing conventions for that language (for example, L->R vs. R->L reading).  This covers labeling as well (i.e. season vs. seasons).

  • By the way, if you think about a full hierarchy using slashes, vs. other suggestions like foo.com/futurama-season-6-episode-9  or foo.com/futurama/s6e9 from an information architecture perspective, or as a tree… the full hierarchy has the advantage of balance… it prevents either really wide structures (both of the previous examples would perform poorly if the episode count got really high), or really deep structures (I think /season/6/episode/9 is too deep).

    The easiest thing is to stop thinking about “seasons” and “episodes” as types, and rather think about “sixth season” and “ninth episode” as specific resources.  That way you could have:


    which would greatly simplify your unease with mapping key-value pairs to a hierarchy, as well as keeping the tree balanced in terms of both breadth and depth.

    • Consider thinking about “futurama,”  “futurama, season 6” and “futurama, season 6, episode 9” as resources.


      Every (?) page on the web is a resource. And all these pages get indexed and linked to. Why support an unnecessary hierarchy when you can just describe a deliberate list of resources?

      • Eddie Welker

        A few quick reasons (of many more) why:

        a) that’s the way the web was designed to work.  You’re tossing convention out the window, making it harder for users who are used to that convention.
        b) it’s convention… you say “unnecessary hierarchy,” meaning you see the hierarchy. If we were taking about semantic html, you’d want to use the most expressive way to convey information.  If you turn the question around, why wouldn’t you express a hierarchy as a hierarchy?
        c) let’s say you’ve got futurama-seasons-6-episode-9 in both english and french? the web was designed to send a http response describing the resources contained. You’ll say “just throw the word -french at the end,” which disregards the fact that URI’s weren’t designed only for humans… they were designed for machines to use.  The standard technique has a number of features built in like this.  Everyone who would want to program against your new URI conventions would have to write new code to figure it out.  That’s a waste of time/resources.

  • Dalibor Sojic

    http : //foo.com/futurama-season-6-episode-9 doesn’t look logical for me. It “represents” one resource. It doesn’t looks structural.

    I would use http : //foo.com/futurama/6/9 – this is more structural organization od files/directories

  • How about futurama/season6/episode9?

    Heck, even futurama/season6episode9

  • This is how I’d define my usage of the different punctuation symbols:

    / (Slash) to show hierarchy (series/futurama)
    : (Colon) for defining things, a bit like a selector or filter like the answer to “Which? (season:6)
    – (Dash/Hyphen) to show spans (season:3-6)
    , (Comma) for lists (compare:DesireS,GalaxySII,NexusPrime)

    But, the way you format it depends on the contents of the site. Imagine a site like IMDB. When you visit a tv-series you get a list of all different things you can learn/experience around this site (cast & crew, soundtrack listing, seasons, trivia). This would live on the url /futurama.

    If you then click on seasons you get a list of all seasons (/futurama/seasons). To show more info about one of the seasons, click that one (/futurama/seasons:6). You will then reach a page where you can read a synopsis of the season, see what episodes are most liked/watched/discussed and so on. If you want to see a list of all episodes, choose episodes (/futurama/seasons:6/episodes). When you’ve got the list of episodes in front of you, you decide to watch episode 9 (/futurama/seasons:6/episodes:9).

    We can take it further: Instead of watching the episode on the last mentioned url, you get a short plot outline for the episode, comments about it, references, trivia, connections and other stuff. You’ve also got the option to watch it (leading you to /futurama/seasons:6/episodes:9/watch).

    But actually the url shouldn’t start with /futurama if this schema is used. Instead it should be something like /series:futurama/…

    The strength with this way of writing the url (implementing the usages I mentioned above) gives you a lot of opportunities:
    /series:futurama/seasons:6/episodes:7-9 (show episode 7, 8 & 9 next to each other)
    /series:futurama/seasons:6/episodes:7,9 (show only episode 7 & 9 next to each other)
    /series:futurama/seasons:3-5/episodes:7 (show s3e7, s4e7 and s5e7 next to each other)
    Having three episodes of futurama running next to each other might be a bit too much, but for other uses this could be a good solution.

    I started something above that I should complete: If there’s a site with only tv-series episodes and nothing else, no extra information or anything, then this way of writing the url might give unwanted results:
    /futurama/seasons:6 should give you a list of episodes for season 6.
    /futurama/seasons:6/episodes should give you the same list (of episodes from season 6). This is something that we don’t want (SEO and everything). One solution could be to redirect seasons:6 to seasons:6/episodes (or the other way around).

    Also, you’d have to decide whether you want to use the plural (seasons:6) or the singular (season:6) form. Or you could go for seasons when in “show all” view and season when only showing one.

    Last but not least, I don’t thing hyphen/dash should be used for separation, it’s used to join words in most languages (that I know of), as in “first-class” or “low-budget”.

    Does it make sense?

    • Kévin Thommy

      I’m totally into that logic-based & multi-purposes, great ideas here.

      I have to disagree on that “colon” character though. Colon in an URL is meant to precede the server port; and I don’t like using stuff that has a meaning already. The slash is fine : it means hierarchy, and still means that in your URLs; but I would go back to
      or something.

      ? Looks a bit funny but the meaning & reading is ok … Dunno if that’s an improvement or just another weird idea, thought. There is one good thing with slashes-only URLs : it’s a (unofficial) standard. Standard is good.

  • In italian keyboards there are 3 very unaccessible symbols: %, & and / . They are found on top of 5, 6 and 7 and have the most uncomfortable key combination ever. Even more than “grab a portion on the screen to the clipboard” on osx.

  • On your last point about choosing the wrong characters for URL’s you way want to read this post 😉

  • Nonono

    I always look at URL as a directory structure, so I prefer: http://foo.com/futurama/season-6/episode-9/

  • Brent

    http://foo.com/futurama/season-6/episode-9/ definitely my preference on newer projects.

    Super intuitive to jump to the season episodes list page….


    Also intuitive to jump back to the season list page….


  • Brent

    foo . com / futurama / season-6 / episode-9 / definitely my preference on newer projects.Super intuitive to jump to the season episodes list page….foo . com / futurama / season-6 /Also intuitive to jump back to the season list page….foo . com / futurama /

  • Pingback: cartier ballon bleu white gold for sale()

  • Pingback: 4cyn5et4m5t94c5t9m4vn54cx65()

  • Pingback: http://falschgeldkaufen.blogspot.com/2017/01/wo-kann-ich-falschgeld-kaufen.html()