Download File: Issue with Content-Type on PNG images

  • Profile Image
    Asked on September 07, 2017 at 04:24 PM

    Issue with Content-Type on image, it shows 'application/octet-stream' instead of 'image/png'

    It prevent us from using those image as our server check first if it's an image and fail to do it because of wrong Content-Type.

    Here the sample code in Python that I used.

    >>> import requests

    >>> r = requests.get('')

    >>> r.status_code


    >>> r.headers

    {'Date': 'Thu, 07 Sep 2017 16:50:53 GMT', 'Transfer-Encoding': 'chunked', 'Content-Type': 'application/octet-stream', 'Content-Disposition': 'attachment; filename="Screenshot 2017-09-07 13.58.07.png"'}

    Thanks in advance for your swift answer.


  • Profile Image
    Answered on September 07, 2017 at 05:23 PM

    From what I understand, you were using your own custom script(Pyhton) to validate the content-type of the uploaded image in the form

    But I believe this is not related to the form. The uploaded image content-type integrity actually comes from the source data (the uploaded image file). The form Upload field only uploads the file to JotForm but it does not change or modify the content-type of the source file.

    I hope this help. Please let us know how we can be of further assistance.



  • Profile Image
    Answered on September 10, 2017 at 06:14 AM

    The Python script mentioned here only *retrieves* the image, it is not involved in validating / sending images at all.

    The issue we are facing is:

    - the user uploads a PNG image using the form

    - when we query the image, the Content-Type returned by Jotform for the image is "application/octet-stream" instead of the expected "image/png"

    => the original Content-Type of the image got lost somewhere during the upload process


  • Profile Image
    Answered on September 10, 2017 at 08:38 AM

    We are sorry for the inconveniences.

    However, as far as I understand, we intentionally use the 'application/octet-stream' content-type to tell that this is a binary file and it should be downloaded to the disk. One of the reasons is that we do not want to be used as a web host for files (which may generate huge traffic and affect other users). We use the same content-type for downloads of the other file types too.

    We can forward a ticket to our developers regarding the issue, but I do not think that this behavior will be changed anytime soon.

  • Profile Image
    Answered on September 11, 2017 at 05:44 AM

    The header that triggers download to disk is Content-Disposition, which you set correctly to "attachment".

    The Content-Type header specifies the nature of the file. If you set it incorrectly, you can expect browsers (especially on mobile devices) to not know what to do with the file. As a result, after download users will get a message saying they do not know with what app to open the file.

    Mangling the Content-Type is in essence a data loss issue : you were given the correct information by the browser that uploaded the file, but you do not return this information when retrieving the file. As such it should really be fixed.

    Thanks in advance!

  • Profile Image
    Answered on September 11, 2017 at 07:55 AM

    Please note that application/octet-stream is actually a generic content type. This is ensuring the browser to show the "open with" download dialog to open the file in appropriate application instead of setting specific content type. 

    I believe this is part of our application and not possible to change it. I will still go ahead and report it to our backend team. We will get back to you as soon as we have any update from them.