In times like these, the official HTTP specification is always helpful. From (my emphasis added): Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body. If and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource.

1. Application Octet Stream

If the media type remains unknown, the recipient SHOULD treat it as type 'application/octet-stream'. The cause of your issue is that the server accepting the file upload does not itself know what type of file has been uploaded.

Because it relies on the the HTTP message which sent the file to specify a Content-Type header to determine the exact mime-type. The browser has likely not sent a Content-Type header and the server has assumed application/octet-stream as per the official HTTP specification excerpt above. It's also possible that the client uploading the file opted not to determine the mime type of the file it was uploading and sent the Content-Type: application/octet-stream header itself.

Application Octet Stream

Now, when we consider this in conjunction with the, we see the following: $_FILES['userfile']['type'] The mime type of the file, if the browser provided this information. An example would be 'image/gif'. This mime type is however not checked on the PHP side and therefore don't take its value for granted. So as you can see, even if $_FILES['userfile']['type'] is specified, it only corresponds to the Content-Type header sent by the client. This information can easily be faked and should not be relied upon.