Running a Nibbler analysis on a static website I just built, I got the following feedback:

Avoid use of file extensions wherever possible. File extensions appear at the end of web addresses, and have several negative effects. They make the address harder to remember or type (particularly for non-technical users), and can reveal the underlying technology of the website making it very slightly more vulnerable to hackers. They also tie the implementation of the website to a specific technology, which can make subsequent migration of URLs difficult.

The above message is a result of having a flat directory structure and linking directly to the individual web pages (whatever.html). So is it really that much better to put every html file on a website in its own personal subdirectory (giving every webpage the file name index.html and relying on the directory name to identify the file) vs simply linking directly to the individual html files? I did some searching but didn't really find anything useful. This discussion had some info but didn't answer my question.

I'm curious to know what folks think of the two different approaches. Thanks.

  • 2
    /file-name/ is a directory. /file-name is a file.
    – Rob
    Sep 7, 2021 at 9:42
  • 1
    This claim seems odd to me for most uses, as how often are URLs meant to be typed in and remembered? Normally all you care about is the URL to the site. Also, if you type a URL with a / at the end, it is generally treated as if the / wasn't there. Try adding a / to the end of this URL. No one cares if it's actually directory or a file.
    – trlkly
    Sep 7, 2021 at 9:47
  • 3
  • 2
    @Rob "/file-name/ is a directory. /file-name is a file. " No, not necessarily. There is no 1-1 mapping from URL to filesystem. The whole underlying engine can be some sort of dynamic page generation, and path elements could merely reflect some routing, irrespective to what is on disk. Sep 7, 2021 at 15:41
  • 2
    @Rob "The web is based originally on Unix and in Unix that's a directory. " You seem to forget, or put aside, that HTTP and URLs, by definition, is an abstraction that do not force anything really about how data is retrieved on the server, that is its own prerogative. See for example, also coming from Unix, the /~johndoe/ convention, and you could say that is a directory too, which is kind of true, except that the directory is not called itself ~johndoe but more probably /home/johndoe/, and this shows the abstraction/level of redirection (unrelated to HTTP redirections) Sep 7, 2021 at 18:12

4 Answers 4


You have several options for removing extensions. You don't have to create a directory for each file.

  • Use Apache's mod_negotiation with multiviews. You enable it with Options +multiviews in your .htaccess file. Then you can link to <a href="some-page"> and Apache will find some-page.html and serve it. Same goes for <img src="some-image"> for which Apache will automatically serve some-image.png, some-image.jpg, or some-image.gif if any of them exist.
  • You can save your files without a file extension. However that introduces other problems: Its difficult to configure your server to serve the correct content type for different files and it will make editing the files harder for you.
  • Use mod_rewrite to remove extensions from some files.
  • Use a front controller to serve your entire site from one script that does its own content mapping based on the URL. That is how most content management systems such as WordPress work.

Before you go and do any of that, I'd suggest that you read Jesper M's answer to the question that you linked. Having the extension match the mime type can be beneficial when somebody saves something from your site locally. If your page gets saved locally as some-page.html it will likely work correctly but if it gets saved as just some-page without an extension, the user may not be able to open the file. I'd recommend removing extensions from the URL that indicate what scripting language you are using (.php, .cgi, .asp, etc) but not necessarily removing extensions that indicate the file type (.html, .png, .jpg, etc.)

As far as SEO goes, it doesn't matter if you have file extensions or not. Google doesn't give much (if any) weight to what your URL looks like right now. I'd focus on how your URLs impact usability: descriptive, reasonably short, and maybe a file extension that matches the file type.

  • " If your page gets saved locally as some-page.html it will likely work correctly but if it gets saved as just some-page without an extension," The browser can suggest adding an extension, based on content-type. This is separate from how the content was retrieved (which URL). Sep 7, 2021 at 2:42
  • @PatrickMevzek from a practical standpoint modern browsers don't always add extensions. I use Firefox. If I use ctrl-s to save the current page, FF will add an extension. However if I right click on a link and choose to save that link, FF will not add an extension. Sep 7, 2021 at 9:43

A document that is not often read but should be:

https://www.w3.org/Provider/Style/URI.html "Cool URIs don't change"

To extract the parts relevant to your question:

So what should I do? Designing URIs


What to leave out

Everything! After the creation date, putting any information in the name is asking for trouble one way or another.


File name extension. This is a very common one. "cgi", even ".html" is something which will change. You may not be using HTML for that page in 20 years time, but you might want today's links to it to still be valid. The canonical way of making links to the W3C site doesn't use the extension.

In fact, the web is just an extension of an earlier practice started by brain-dead OS: having to put an extension to a filename to just denote its content. This is at best metadata and at worst can be inferred from the content. But as this existed it leaked to the web. If you are old enough, you know by that time that some people had to use index.htm instead of index.html because of other brain-dead OS limitations in filenames.

It may not be true anymore today, but some bad/old/non-conforming software might deduce actions to do based on the name, instead of honoring what is in content-type.

So then the question could be rephrased as:

Best form for URLs: file-name or /file-name/

And now it is 100% subjective. Or at least the answer is far too dependent on local circumstances that no external tool could take into account. For example, if you have various rules in your webserver regarding the path, the regular expressions can be simpler with /file-name/ (because there are clear delimiters) instead of just file-name.


"(file extensions) can reveal the underlying technology of the website making it very slightly more vulnerable to hackers" is humorous. It is trivial to find out the underlying technology with or without extensions.

Your idea " to put every html file on a website in its own personal subdirectory (giving every webpage the file name index.html and relying on the directory name to identify the file) vs simply linking directly to the individual html files?" will work but you are possibly creating a nightmare trying to maintain the site if it starts to get large, all those "index.html" files :o( Add to that, any rearranging of the site structure will be difficult. Plus links from one page to another are going to get complex. Don't do it, it isn't necessary.

I can see the advantage of not having a file extension e.g. .html or .php, that can be done via a .htaccess. There is a similar question here https://stackoverflow.com/questions/13540353/using-htaccess-to-remove-php-file-extension-from-url


The suggestion is almost purely cosmetic; Google doesn't care. I guess if you decided to blaze your own trail and make all of your page extensions .jpg then you can deal with the fallout of such a silly decision.

Yes, file extensions can be considered ugly but maybe some people think they're beautiful. Think about when's the last time you had to manually type out a URL?

The benefits stem from a primarily server-side administration perspective.

Consider this URL: https://mashable.com/article/singapore-police-patrol-surveillance-robots

It's basically domain/page-type/unique-article-slug and this is likely consumed by an MVC architecture which is not dealing with a physical file but rather making a database call to retrieve the content.

If your website is static then it's basically a "meh" situation and you have to ask yourself whether you want to get on the extension-less bandwagon. This can be achieved purely through a single .htaccess rewrite (not redirect) directive.

If you have a bunch of dynamic user-generated content or are building an administrative interface then the allure of an MVC architecture or something more robust cannot be ignored.

  • Traditional server side content management systems and code frameworks for the web use the model-view-template (MVT) rather than the model-view-controller (MVC) model: geeksforgeeks.org/… Sep 7, 2021 at 16:38
  • @StephenOstermiller django is the only MVT framework I've been able to find. Are there other examples? It's hard to consider one example to encompass "traditional CMS" options. What about MVP, MVA, or MVVM? Regardless, the distinction is hardly relevant given that the URL slug-ification is the meat-n-potatoes of my answer. The implementation details aren't really relevant. I'm just most familiar with MVC since it has withstood the test of time.
    – MonkeyZeus
    Sep 7, 2021 at 16:56
  • 1
    Until recently there are very few true MVC frameworks for the web. Django is one of the few that acknowledges that fact. With the view on the client, a controller on the server has a hard time to updating that view. Some newer frameworks for the web are starting to MVC by moving the controller to the client in JavaScript or by using web sockets to push data from a controller on the server to the view on the client. Sep 7, 2021 at 17:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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