How important is the file extension in the URL for images?

[dsbud]

I know that descriptive image file names are important for SEO. But how important is it to include .png, .jpg, .gif (or whatever file extension) in the url path? i.e. https://example.com/images/golden-retriever vs. https://example.com/images/golden-retriever.jpg

Furthermore, since you can set the filename in the Content-Disposition response header, is there any need to include the descriptive filename in the URL path?

Since I'm pulling most of our images from a database, it'd be much simpler to not care about simulating a filename, and just reference an image id in my templates.

Example:

1. Browser requests GET /images/123456
2. Server responds with image setting both Content-Disposition, and Link (canonical) headers

Content-Disposition: inline; filename="golden-retriever"
Link: <https: 123456="" example.com="" images="">; rel="canonical"</https:>

[willcritchlow]

In theory, there should be no difference - the canonical header should mean that Google treats the inclusion of /images/123456 as exactly the same as including /images/golden-retriever.

It is slightly messier so I think that if it was easy, I'd go down the route of only ever using the /golden-retriever version - but if that's difficult, this is theoretically the same so should be fine.

[dsbud]

@Will Thank you so much for this response. Very helpful.

"If you can't always refer to the image by its keyword-rich filename"...

If I'm already including the canonical link header on the image, and am able to serve from both /images/123456 and /images/golden-retriever (canonical), is there any benefit to referencing the canonical over the other in my image tags?

[willcritchlow]

Hi James. I've responded with what I believe is a correct answer to MarathonRunner's question. There are a few inaccuracies in your responses to this thread - as pointed out by others below - please can you target your future responses to areas where you are confident that you are correct and helpful? Many thanks.

[willcritchlow]

@MarathonRunner - you are correct in your inline responses - it's totally valid to serve an image (or other filetype) without an extension, with its type identified by the Content-Type. Sorry that you've had a less-than-helpful experience here so far.

To answer your original questions:

1. From an SEO perspective, there is no need that I know of for your images to have a file extension - the content type should be fine
2. However - I have no reason to think that a filename in the Content-Disposition header will be recognised as a ranking signal - what you are describing is a rare use-case and I haven't seen any evidence that it would be recognised by the search engines as being the "real" filename

If you can't always refer to the image by its keyword-rich filename, then could you:

• Serve it as you propose (though without the Content-Disposition filename)
• Serve a rel="canonical" link to a keyword-rich filename (https://example.com/images/golden-retriever in your example)
• Also serve the image on that URL

This only helps if you are able to serve the image on the /images/golden-retriever path, but need to have it available at /images/123456 for inclusion in your own HTML templates.

I hope that helps.

[Martijn_Scheijbeler]

If you really did your research you would have noticed the header image is not using an extension.

[dsbud]

Again, you're mistaken. The Content-Type response header tells the browser what type of file the resource is (mime type). This is _completely different _from the file extension in URL paths.

In fact, on the web all the file extensions are faked through the URL path. For example, this page's URL path is:

https://moz.com/community/q/how-important-is-the-file-extension-in-the-url-for-images

It's not

https://moz.com/community/q/how-important-is-the-file-extension-in-the-url-for-images.**html**

How does the browser know the the page is an html doc? Because of the Content-Type response header. The faked "extension" in the URL path, is unnecessary.

You can view http response headers for any URL using this tool.

[Martijn_Scheijbeler]

https://finance.yahoo.com/news/brutal-poll-shows-most-people-214647063.html Good luck!

[Martijn_Scheijbeler]

Do you need a new keyboard?

[Martijn_Scheijbeler]

@James Wolff: I'm really hoping you're being sarcastic here. As it's totally fine to serve it without the extension. There are many more ways for a crawler to understand what type a file is. Including what @MarathonRunner is talking about here.

[dsbud]

This isn't accurate. File extension (in the url path) is not the same as the **Content-Type **response header. Browsers respect the response header Content-Type over whatever extension I use in the path.

Example: try serving a file /golden-retriever.png with a content type of image/jpeg. Your browser will understand the file as a .jpg. If you attempt to save, your browser will correct to golden-retriever.jpg.

You can route URLs however you want.

Additionally, I'm not aware of any way browsers "leverage cache by content type". Browsers handle cache by the etag/expires header.