The HTTP standard suggests using Content-Disposition: attachment with Content-Type: application/octet-stream to prompt browsers to show a “save as” dialog instead of displaying the file.
But if the file is a PDF or image, should I still use application/octet-stream or the specific MIME type? When is application/octet-stream necessary
I’ve learned that using Content-Disposition: attachment is the main trick to prompt the “save as” dialog in browsers. The Content-Type: application/octet-stream is like a generic binary type that forces browsers to treat the file as downloadable.
But if you’re sending a PDF or image, I usually keep their specific MIME types (application/pdf or image/png) because that helps some browsers preview the content inline if needed.
Use application/octet-stream mainly when you want to force download regardless of file type.
In my experience, Content-Type: application/octet-stream is often used to tell browsers, “Hey, this is just raw binary data, don’t try to open it.”
But it’s not always necessary if you already set Content-Disposition: attachment. For files like PDFs or images, I prefer using their actual MIME types along with the attachment header. This way, the browser has accurate info and still triggers download. So application/octet-stream is mostly for unknown or generic binary files.
I used to think you had to always set Content-Type: application/octet-stream to force downloads, but it turns out that Content-Disposition: attachment is what really controls that behavior.
If you want users to download PDFs or images instead of viewing them, setting attachment is enough. Keeping the correct MIME type helps with things like antivirus scanning and compatibility.
I only switch to application/octet-stream if I’m dealing with files that don’t have a clear MIME type or I want to block inline rendering completely.