I've always wondered about this and never found a good solution.

But this question reminded me of it.

When I have a URL on my website it can be displayed and accessed any of the following ways:



Now, I can understand the merits of adding keywords in the URL. Even the most basic SEO guide will mention to do just that. ... but for the sake of sanity, clarity, ease of reading, ease of use, and so on, including web compliance ...

Is it preferred to have a file-extension or not?

Really, deep down my logic tells me: yes, it should. The reason being is this stems back to the days of the past when the internet was mostly USENET, FIDONET, FTP and GOPHER.

See, if a URL has no filename, then it normally is considered a directory. This is where index.htm came about, because this by default lists the directory if no index file is found. However, soon enough, web programmers started overriding this and using index.htm to actually serve the content of that web directory as a page. The main difference, was markup language was added in, and this was parsed in the browser. With this markup language, the Content-Type:text/html; tag in the response header became the indicator to what filetype it was for any file. HTML seems to be the only "filetype" that just doesn't have consistently named extensions, except for when they are saved.

Unfortunately, once web pages became the main thing, it became a security error to actually display the directory contents, so everything stayed hidden with only the actual URL content being displayed.

Not to mention the cross-platform file-naming wars.. windows based require a 3 or less digit extension, and unix/mac can have more. So should it be .HTM or .HTML or NONE and let the platform decide?

So in essence, I guess what I am trying to figure out is beyond SEO and dealing more with aesthetics and web compliance.

  • How would you set this up? In your .htaccess file? I mean, change the path for a .html-file to look like the first example?
    – Zolomon
    Commented Sep 27, 2010 at 6:48
  • 1
    @zolomon you can do that, or better yet use a dynamic URI parser like the way Wordpress does and redirect *.* to that. Commented Sep 28, 2010 at 7:05
  • SEO is not the whole life. Extensions are useless, especially in the realm of HTTP as the Content-Type metadata (HTTP header) defines what the content is, irrespective to the URL. Only bad software/OS has to rely on extensions to know what to do. See w3.org/Provider/Style/URI.html Commented Jul 11, 2021 at 5:09

7 Answers 7


Use a .extension where there is more than one representation or where the client software is absolutely stupid and refuses to accept the Content-Type alone (QuickTime, RealPlayer, Outlook, etc I am looking at you):

  • http://www.somesite.com/subdirectory - this can be your auto-negotiation version that uses Canonical META tags to point to the actual representation

  • http://www.somesite.com/subdirectory/ - it is always worth supporting trailing slashes on any URL but using Canonical META tags (not redirects as this is an unnecessary slow down) to point to the correct URL

  • http://www.somesite.com/subdirectory/index.htm and http://www.somesite.com/subdirectory/some-relevant-keywords.htm - the three character extension limit doesn't apply to HTTP (only the underlying FileSystem/OS) so the client can save this as index.html or a.a if they wanted to, whilst still being able to access it

  • http://www.somesite.com/subdirectory/index.html - if you serve a .atom, a .xml or similar version then it makes sense to also honour the .html version (and Canonically link to it via LINK tags on the auto-negotiated version) - use HTTP Content-Location headers to point to the auto-negotiation version though - remember you can also go multi-lingual (.en, .es, etc...) or multi-charset (.utf8, .utf16, etc...)

  • http://www.somesite.com/subdirectory/index.php and http://www.somesite.com/subdirectory/index.asp - unless you are serving the source code then these make no sense to support

  • http://www.somesite.com/subdirectory/some-relevant-keywords - SEO is a constantly changing art and if this works for you then great

  • http://www.somesite.com/subdirectory/index.php?page=some-relevant-keywords, http://www.somesite.com/subdirectory/?page=some-relevant-keywords and http://www.somesite.com/subdirectory/?page=some-relevant-keywords&even=more-keywords - if there are an infinite number of ways to manipulate the content then this is great - but usually pages deserve their own URL not a query string and these type of URLs are to be avoided (try getting someone computer illiterate to type one of those in)

  • 1
    Multilingual extension? That's the first time I see something like that. I remember reading that Google prefers folders like /es/subdirectory/index.html even more than subdomains http://es.example.com/subdirectory/index.html. Do you have any information on how well the .es extension is supported by search engines? Because I would love it use it. (Also could you combine them? like /index.utf16.es?) Commented Apr 4, 2014 at 19:28

I would say don't include the file extension if the software you're using allows you to omit it. So from your list of examples, my preference would be:


Browsers don't care whether something is a directory or not on the site, or whether it's a HTML file, a .asp file or whatever - they simply make a HTTP request and get a HTTP response. So if the extension is superfluous, drop it.

This also has the added benefit of making your URLs more concise (and easier to read out on the phone - "example dot com slash products" is much nicer sounding than "example dot com slash products dot h t m l"), and making it easier to switch technology in the future (as no URL change would be required).

  • 4
    I am swaying towards this one as best-practice, due to SEO and asthetic reasons. Commented Sep 19, 2010 at 23:54
  • Yes, browsers does not care, but servers care if it is asp, aspx, or some other type that will require extra processing on the web server.
    – awe
    Commented Jan 19, 2011 at 6:47
  • Revisiting this after many years, best-practice appears to have prevailed. Yet I still wonder what will happen when web-crawler logic eventually learns to parse operands. e.g. some-relevant-keywords has equivalency of (some) (!exclude->relevant) (!exclude->keywords) Causing every SEO expert to change it suddenly to some+relevant+keywords destroying the aesthetic and readability of using hyphens as separator characters. Root cause: /?query=some-relevant-keywords is already the literal exclusion. Commented Mar 28, 2018 at 21:46

Cool URIs don't change. (Go to to the section titled "So what should I do? Designing URIs")


Is it preferred to have a file-extension or not?

There is nothing in the RFCs to mandate having file-extensions, neither is there anything requiring you to leave them out. It's a choice you make.

Conformant HTTP URIs don't need file extensions for anything. There is a rich set of HTTP headers (especially the MIME type) to handle everything that file-extensions are otherwise used for.

That said, most browsers today do in fact rely on a combination of MIME type, extension, and binary 'fingerprint' of the first bytes to determine content type. This can sometimes give surprising results, and so it's important that we webmasters set the right headers (and possibly disable content type sniffing if we are 101% sure our headers are correct).

There is one situation where file extensions are useful: If the end user saves content from your site to his local computer for later use. Theoretically a 'smart' browser should ensure that saved content works for the local computer type; but in practice you can help everyone by serving up content with industry-standard extensions like .jpg , .mp4 , .css etc. In my experience all browsers handle the HTML type properly. You don't need to add a .htm / .html extension on HTML yourself, the browser will handle this specific content type correctly.

Security: One could argue that there is a security benefit in hiding which platform you're using (.php / .asp etc). That's true. In practice I think any good hacker will discover this right away, so I don't think hiding these extensions for security alone is worth the trouble.

Special consideration: If you plan to use a CDN in the future, and your CDN is of the "push" type (content is uploaded to the CDN beforehand fx via SFTP), then you might want to keep file extensions. Most 3rd party systems look at file extensions to discover which MIME type to serve up the content with.

My personal choice has become:

  • When HTML is generated dynamically by my webapp, I do not add a 'fake' .html extension to mimic a directory and file structure that isn't actually there. I normalize URLs and I standardize the URL format used for reasons of SEO. I personally prefer having a trailing slash on the last leaf of the URL, i.e. http://example.org/first/second/ , but that's a matter of taste.

  • When we are in fact talking about actual files that are uploaded to a harddisk somewhere, then I keep the 'normal' file extension for the type. So .css / .js / .exe / .mp4 etc are in use for these kinds of content.

  • One thing, adding .htm to mimic a directory (rather overriding index.htm) is really not "fake" since you are serving HTML content. It would be fake if the content was not HTML. Commented Sep 19, 2010 at 23:49

I've done a little informal experimentation, and what I discovered surprised me but makes some sense.

From a content-being-delivered-to-the-user standpoint, as well as screen scraping, the Content-Type rules the day.

However, the presence or absence of an extension, as well as what that extension is, seems to sway search engine visits.

When I omitted any extension at all, I got relatively few hits -- as if the URL were a location or dynamic content and therefore not worth indexing very much.

When I changed the same links to use an .xml extension, because the pages were actually generated by XSLT (on the server side), the indexing actually dropped further -- perhaps because it thought it was merely data or the result of some programmatic request.

When I changed the same links to use .html, search engines went wild with the site.

At the moment, my site handles all three transparently, but when it provides a clickable link, I return the .html version of the URL.

I'd like to think search engines were a little smarter, or a little less biased, but that's what I've observed happen with my pages.

  • won't having multiple URIs for the same resource cause dupe pages though? Commented Sep 19, 2010 at 23:46
  • Technically, I'd suppose so, and I suspect the proper thing to do then is have the others simply perform a redirect. Commented Sep 21, 2010 at 23:35
  • this is indeed very surprising! can you provide any more background information, like which search engines, to what extent you noticed the change, etc.?
    – damusnet
    Commented Oct 14, 2010 at 11:43
  • I have suffered a huge drop in traffic and while I am still not sure, I think in coincided with the moment I switched from rel canonical with .html to one without.
    – Dan
    Commented Mar 1, 2014 at 19:45
  • Sorry to reply so late, but I remember a while back Matt Cutts mentioning to use a .html if possible. (more here). It kind of makes sense that search engines are sensitive to extensions, just imagine seeing http://example.com/index.exe Commented Apr 4, 2014 at 19:37

No, you shouldn't use a file extension for normal page types unless you absolutely need it for a technical reason. How does it improve the user experience? It's more to type, yet it tells them nothing useful. What will they be able to do knowing that your site is PHP, ASP, etc? A URL is simpler, cleaner, more usable, and more memorable without a file extension.

See, if a URL has no filename, then it normally is considered a directory.

I don't think I agree. Generally, a URL is a directory only when it has a trailing slash. Without a trailing slash, it's considered a file.

  • User experience: if the file extension is .php or .asp if the user saves it, it would be an unknown filetype and computer illiterates may not know how to re-open it. With no filetype, the browser would add it, but possibly this hinders some search engines? Commented Sep 19, 2010 at 23:52

You should only add a file extension, if the content behind the URI is actually a file. But even then you could drop it, if there's only one representation of it (JPG, PDF, ...).

If there are multiple representations, the HTTP-way would be to have the format negotiated through the Accept header. But if you want your users to have a say in it, you probably would want to have an extension so they can choose which representation they want (JPG, PNG, ...) by requesting the one or the other URI.

  • This is more involved than just image or other resources. For non-html resources, I would always use a file extension. Most browsers will not know what to do if its left out if the user happens to do "save-as". Sure you can add the filetype in the header, but once saved client computers would not know how to re-open the file. Commented Feb 25, 2013 at 16:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.