It already works and you don’t have to do anything
I’m not sure if you are already aware of that or not but to remove .html extension from GitHub Pages all you have to do is remove .html extension from your links.
In other words it already works and you don’t have to do anything. You don’t have to use subdirectories, CNAME, redirects, Jekyll _config.yml, YAML front-matter or any other hack suggested in all of the answers here.
Examples
For example you can use:
- https://rsp.github.io/gh-pages-no-extension/test1
instead of:
- https://rsp.github.io/gh-pages-no-extension/test1.html
and it displays the same file.
Just change the links in your links and that’s it.
Tests
I made some tests to demonstrate how it really works where you can click links and it highlights which file is loaded with which URL, including warnings about insecure redirects in certain cases.
For eaxample, the link:
- https://rsp.github.io/gh-pages-no-extension/test1
shows that it is displayed by the test1 in the URL but actually displays the file test1.html:
Problems with other solutions
Using things like index.html in special subdirectories as suggested here in other answers will not do what you want, which is simply serving the example.com/name.html when asked for example.com/name, but would instead give you a 301 redirect to example.com/name/ (note the trailing slash) which in turn would give you the contents of example.com/name/index.html file.
That leads to the following problems: you are in a different directory and you need to use <a href="https://stackoverflow.com/questions/21244910/name"> instead of just <a href="https://stackoverflow.com/questions/21244910/name"> for links to other pages on the same level and the same goes for all assets (or you can use absolute paths as someone suggested which is not a good idea on GitHub pages – especially project pages – because after forks and projects renaming you have to remember to update all of the links and js/css assets in all of the html files).
The other thing is that now you have a useless redirect for every navigation – which incidentally redirects from HTTPS to HTTP (from secure URLs without the slash to insecure URLs with a slash), e.g. see:
- https://rsp.github.io/gh-pages-no-extension/dir (secure HTTPS)
which (at the time of writing) redirects to:
- http://rsp.github.io/gh-pages-no-extension/dir/ (insecure HTTP)
and NOT to:
- https://rsp.github.io/gh-pages-no-extension/dir/ (secure HTTPS)
as you might expect, so make sure that you are aware of that. See:
(Note that this image is linked to a secure HTTPS URL but you end up using an insecure HTTP connection – you may need to use incognito mode to see that.)
This is how the headers look like, as of June 17, 2016:
$ curl -I https://rsp.github.io/gh-pages-no-extension/dir
HTTP/1.1 301 Moved Permanently
Server: GitHub.com
Content-Type: text/html
Location: http://rsp.github.io/gh-pages-no-extension/dir/
... ^^^^
Hopefully GitHub will fix that in the future.
(I discovered it when I was writing this answer almost a year ago and this problem is still present as of June 2016.)
Though strangely enough, as of June 17, 2016 (I’m not sure if it always was the case because I noticed it recently while updating this answer) this URL:
- https://rsp.github.io/gh-pages-no-extension (secure HTTPS)
redirects to:
- https://rsp.github.io/gh-pages-no-extension/ (secure HTTPS)
as it should. See the headers:
$ curl -I https://rsp.github.io/gh-pages-no-extension
HTTP/1.1 301 Moved Permanently
Server: GitHub.com
Content-Type: text/html
Location: https://rsp.github.io/gh-pages-no-extension/
... ^^^^^
The only difference is that it is a project root URL and not a deeper directory inside the project (see the project structure) so the buggy redirect seems to be present only in deep links inside a project’s GitHub Pages and on one browser I tested only when you use incognito mode.
The bottom line is that you need to be careful. My advice would be to avoid all redirects altogether and only use those URLs that don’t result in any redirects at all.