Trailing Slashes Best Practice

Published in Search Engines on Friday, July 16th, 2004

What is the right thing to do about trailing slashes? A look at some links and examples, and what is Yahoo! up to?

I originally became aware of the issues surrounding trailing slashes in article #138 of Alistapart, "Slash Forward (Some URLs are Better Than Others)". Kyler Laird provides some additional information about trailing slashes.

Inconsistencies amongst the ranks

Having read those and put them to work (over two years ago now), I felt reasonably comfortable about how I dealt with URL's. Unfortunately, some doubt has been cast over my previously comfortable state, seeing respected peers laughing in the face of convention.

Note: Simon likely gets away with it in the way that he has programmed his site and written his re-write rules... He has been observed in the commenting wild supporting the use of the trailing slash.

Yahoo! says "It looks cooler without the slash, man"

Now admittedly, (sounding like a big geek here) the url's sans trailing slash do look cooler, but if the lack of a trailing slash can result in a performace issue, how is it that a site like Yahoo! chops the trailing slash off of urls that don't end with file extensions?

Look closely at the urls of the search results (both the green ones and the urls in their anchors), and if you don't have a file extension, no trailing slash for you!

For the record, Google includes the trailing slash.

What's the rule, then?

Given the inconsistencies, what is right and what is wrong?

Comments and Feedback

Personally I believe that the trailing slash should always be used for accessing directories (indices).

However, pages (*.htm, *.asp, etc.) will obviously be presented without a trailing slash and, ideally, without a file extension (see: Cool URIs don't change). Thus Simon Willison's URL handling is not only "cool", it's also correct and future-proof.

Ralf S. Engelschall's Apache module"mod_rewrite" is perfect for presenting correct URLs, rewriting any incorrect ones that the user enters. With the availability of such tools, there is no reason why incorrect (or uncool) URLs should ever be seen.


For my redesigned site, I have adopted a policy of always having the trailing slash - even with URLs rewritten with mod_rewrite. Incidentally, Simon Willison now advocates the trailing slash.

Thanks Simon, I knew I saw that somewhere, that's why I added that note in the post.

The catch here is, if you rewrite your urls, you could feasibly have everything after the root trailing slash be a (lang="php") QUERY_STRING, and so Apache may never append the trailing slash as described in the Alistapart article quoted above. So then why use the trailing slash? I would imagine for consistency?

Anyways, in this blog, links sans trailing slash, and for that matter links lacking the www, are 301 redirected to the full www (an SEO thing) with trailing slash.

Humberto Oliveira Fri, 16th of July, 2004

I wasn't aware to that fact at all. I am going to think about including the trailing slash on my links.

As a developer bound to Microsoft tecnologies, I don't now exactly how the Apache mod_rewrite works. I have being developing content management systems that relies heavily on url rewriting using custom ASP.NET http module classes to provide this functionality.

The problem is that I can not remove the .aspx extension of the pages due to the fact that I need the request to be processed by the Asp.Net ISAPI Filter. The only solution would be to set the IIS server to pass all the file request directly to ASP.Net but most shared hosting companies do not allow that.

I think I'll be using / for now on.

It seems the best option: trailing slash for directories, and (trailing?) extensions for files. I'm not too confident in losing extensions alltogether, because it gives the user (read: me) an expectation of what migt happen if I click that link. If it's .jpg, I'm fairly certain it will open up a picture. If it's got .mov at the end, I know my browser wil halt for a second or two to load the quicktime plugin. (and that's why I hate applets for navigation, but I'll leave that subject for another time)

I say that I'm fairly certain, because the sever can pick it up, and dish out something really different. It is a burden and a blessing, because the main reason to leave the extension off is that internal mechanisms can change (i.e. used to be LAMP, and now coldfusion is the servers' configuration). But if it has changed, you can change the links with .php to .cfm in an instant. With the same technique, but now it is only used when neccessairy. More prefrable would be to use a directory (with the slash ofcourse!), so you won't have to worry about such things.

I don't really see the value in removing extensions. Other than another (albeit a very small) load on the server.

Enlightened by this thread, I have tweaked my rewrite rules and CMS a little to generate shorter and more "correct" URLs.

Where appropriate, I have terminated URLs with a trailing slash. If the user omits the slash, then the rewriter will add one - so that when URLs are read out or copy-and-pasted the correct format is used.

I have also removed the extraneous "index.htm" and "page_x.htm" components that the rewriter previously added. Naturally, the old URLs are still parsed correctly - so bookmarks/links/etc will still work.

For example - Where previously you would enter: "", you should now use: "". "" is now "", and so on.

I must admit that I have been influenced in my decision by Simon Willison's comments on the matter. When a heavyweight such as Willison suggests that we, "always stick a trailing slash on as it ends up being less confusing," then that's good enough reason for me to change.

Tom Dahm tells us that using a trailing slash "decreases page load time by reducing the number of times a visitor's browser has to talk to your Web server." Dahm's advice is certainly true for file-system based websites (static pages), it is less accurate today when web pages are dynamically generated for each request and effectively sans file-system.

However, whilst omitting the trailing slash will not result in extra requests being made between client and server, there is still a slight performance hit if the trailing slash is omitted - as the server has to process additional rewrite rules in order to accommodate the omission.

To summarise then: I would advocate the use of the trailing slash wherever possible. It benefits the user when URLs are consistent and performance is also marginally improved.

Humberto - There are a couple of ISAPI Filters for Windows that can do what you need - google for ISAPI rewrite, there is a free version that will do what you need. Unfortunately if you rely on postback in ASP.NET in any of your pages then you'll probably find it breaks the postback. I still like to validate form input myself though, so I've never encountered a problem.

Since I was asked to say so: without! :-)

I'm all in for removing redundancy like 'www', a '/' when there is no "real" directory anyway, et cetera.

This topic, that was settled for me (and Jonathan!), has been called into question by Anne, who says (on his blog) Not needed, only for real directories.

Crap, why didn't I think of this? /some/path/somefile references an extensionless file, while /some/path/somefile/ references a directory residing at that path. That is, they are not one and the same!.

So now what?

The trailing slash issue seems only to be an issue if you are accessing apache like systems that will redirect to a trailing slash if the file does not exist

In reality (ie the world where apache doesn't include lots of hacks to get non trailing slash directory names to rewrite) then there can ba a difference between a/b/c and a/b/c/ in that a parser which traverses urls (like the python framework Twisted's Nevow) can get to the c and then decide on what to do if c is the 'leaf' node or if c is a 'directory' node. If I can do different things then forcing a default decision to use or not use trailing slashes is arbitrary and limiting.

In reality, a trailing slash always implies a child node so a/b/c/ is REALLY a/b/c/<default>

The upshot is that trailing slash or not is dependant on your application/ server/framework/personal opinion. It will help to include the trailing slash on apache like servers. It would also help further by including the default document index type. So on apache you might write a/b/c/index.html instead of a/b/c. This seems to be the optimum in saving 'process' and 'network' usage. I may be comletely wrong however and keep the option to change my mind at any point in the future. If it's good enough for Stephen Hawking, it's good enough for me

is dependant on your application/ server/framework/personal opinion.

I guess that may be the case here, that there is no best practice, just do what works for your app.

I agree with Anne van Kesteren - redundancy should be avoided where possible.

However, the trailing slash is grammatically correct with my CMS as it effectively requests the default page at any given path:

  • /folders/blog/20040719/ - maps to:
  • /folders/blog/20040719/page_1.htm

Within my CMS, "20040719" is a (virtual) directory - there are (or can be) other pages within:

  • /folders/blog/20040719/print.htm
  • /folders/blog/20040719/comments.htm
  • /folders/blog/20040719/etc

The main point, in my mind, is not whether or not we are accessing a directory - it's more a case of building future-proof, technology independent URIs.

URLs without a trailing slash look wrong (to me) when there is no terminating file extension.

I guess the question will be argued for a long time to come, especially as more and more websites move from static pages to database/CMS driven architectures.

I think I'll keep the trailing slashes on my website...

To me, this issue is very simple: if there are pages below the current level, use a trailing slash. If there are NO pages below the current level, use NO trailing slash. This is what I consider good practice and consistant, logical behaviour.

Current level counts for both real directories as well as spoofed directories (i.e. directories that don't exist in the file system but are used for ease of use by some sort of CMS).

So basically, that gives us the following rule of thumb:

If there are pages inside the current level, use a trailing slash. If not, use no trailing slash (even when there is no extension to the "file").

Let's dissect Anne's site for this:
Looking at his menu, I spot a big inconsistancy right away: his HOME link has a trailing slash, his ARCHIVES link does not, his TEST link has one again, and ABOUT and CONTACT do not.
We're looking at a page without a trailing slash, but if we follow any of the Archives' links, we'll quickly see that "Archives" behaves and functions like a directory, as there are several levels underneath it. This is illogical URI design, because the Slash is used to separate directories from subdirectories and/or files, and if you treat a directory as a file, people may think the trailing slash is only optional or so. While we know that virtually everyone on the Web won't bother trying to type in "", it's not illogical to imagine that some people, new to the web, may actually believe it's not necessary to have slashes everywhere. Furthermore, if I'm in an archive like this, and I'm in the year 2004, I may want to manually go to a directory and hit Ctrl-L, End and type "07" to go to July. If there is no trailing slash already there, it means I'll now get a 404 error. When I then look at the URI to see what went wrong ("did I typo?"), I notice that the site is treating (virtual) directories as if they were files. Disgruntled I fix what I consider their design error, by backspacing (ctrl-left won't help much when there's no slash in the middle) and adding a slash manually.
Same principle applies. Current location is presented to us as an end-of-level file, while in reality it's a level itself, a directory, virtual or real. Clicking a link that's now in front of us will show us that our location here was actually a directory. Consistant URI behaviour? I think not.

Nice overview Faruk. I can see now why Simon Willison said that On balance, I'd say always stick a trailing slash on as it ends up being less confusing on the post about rewriting urls over on Simon Jessey's blog.

Home » Blog » Search Engines

Check out the blog categories for older content

The latest from my personal website,

SiteUptime Web Site Monitoring Service

Sitepoint's web devlopment books have helped me out on many occasions both for finding a quick solution to a problem but also to level out my knowlegde in weaker areas (JavaScript, I'm looking at you!). I am recommending the following titles from my bookshelf:

The Principles Of Successful Freelancing

I started freelancing by diving in head first and getting on with it. Many years and a lot of experience later I was still able to take away some gems from this book, and there are plenty I wish I had thought of beforehand. If you are new to freelancing and have a lot of questions (or maybe don't know what questions to ask!) do yourself a favor and at least check out the sample chapters.

The Art & Science Of JavaScript

The author line-up for this book says it all. 7 excellent developers show you how to get your JavaScript coding up to speed with 7 chapters of great theory, code and examples. Metaprogramming with JavaScript (chapter 5 from Dan Webb) really helped me iron out some things I was missing about JavaScript. That said each chapter really helped me to develop my JavaScript skills beyond simple Ajax calls and html insertion with libs like JQuery.

The PHP Anthology: 101 Essential Tips, Tricks & Hacks

Like the other books listed here, this provides a great reference for the PHP developer looking to have the right answers from the right people at their fingertips. I tend to pull this off the shelf when I need to delve into new territory and usually find a workable solution to keep development moving. This only needs to happen once and you recoup the price of the book in time saved from having to develop the solution or find the right pattern for getting the job done..