This is working as intended.  The server uses user agent sniffing to decide if the browser supports WebP or not.  If you open said URL in Chrome, the server serves a WebP image (despite the file extension).  Chrome is just saving exactly what it got from the server, byte by byte.

To test this, try downloading the image with wget:

wget https://ak1.ostkcdn.com/images/products/13251843/Apple-13.3-inch-MacBook-Pro-Late-2016-26f43b72-d41c-4b92-8806-fd8fcd8cedf8.jpg

You will see that the response type is image/jpeg.  However, if you make wget pretend it's Chrome:

wget --user-agent='Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.10 Safari/537.36' https://ak1.ostkcdn.com/images/products/13251843/Apple-13.3-inch-MacBook-Pro-Late-2016-26f43b72-d41c-4b92-8806-fd8fcd8cedf8.jpg

then you get an image/webp response type, and the image takes up 19% fewer bytes.

You can always
* use an image viewer that supports WebP, instead of Windows 7 viewer;
* convert WebP to JPEG with any modern image editing utility;
* install a user agent spoofer extension to Chrome to trick servers into not serving you WebP, at the cost of larger download sizes.

So you're telling me even though the server names a file foo.jpg it may actually really be foo.webp?

Nevermind I re-read your comment, so the answer appears to be yes even though it says the image ends in jpg it's actually webp. I had assumed it would save it as the type of the extension.