Skip links
Main content

Mimetype corruption in Firefox

Saturday 27 December 2008 11:33

If you upload a file through Firefox, it may send the wrong mimetype for this file. This article dives into mimetype handling of browsers, explains why the Mozilla team has a hard time fixing the bug, and what we as developers can do about it.

By Patrick van Bergen

What is the problem?

Webdevelopers have used the mimetype property of an uploaded file to determine the content type of the file. Ideally, this approach to type sniffing is more reliable than using the file's extension, because users change file extensions or remove them altogether. Also, different file extensions map to a single mimetype. In general, the type of content is passed along with the file so that the web application does not need to deduce it.

Mimetypes (Multipurpose Internet Mail Extensions), originally designed for Internet E-mail, are used to standardize the types of content that are used in electronic communication. They are managed by the IETF. Common examples are: image/jpeg (for JPEG images), video/mpeg (for MPEGs), text/html (for HTML files), application/msword (for Microsoft Word documents), and application/pdf (for PDF documents). The mimetype application/octet-stream is used for unknown content types.

When you upload a file, your browser chooses an appropriate mimetype for it. Typically, the web-application stores the mimetype of the uploaded file and sends it to the browser when another user downloads it. The downloading browser knows from the mimetype how to handle the file. This is ideal because the user can change the filename in any way he/she likes and the web-application and browsers will have no problem with it. Moreover, there would be no need to keep an association list for file extensions and mimetypes.

Through Firefox (and Mozilla browsers in general) however, your web-application may receive erroneous, of even non-existing "mimetypes" along with an uploaded file. Common nonexisting types are application/download, application/force-download, octet/stream (i am not kidding!) and application/unknown.

Why does firefox do that?

First of all: this is a feature of Firefox, resulting only in a bug if not properly used.

Firefox is trying to be flexible. To that end it learns from experience. It connects extension / mimetype / handler information in a user profile file called mimeTypes.rdf, in the folder \AppData\Roaming\Mozilla\Firefox\Profiles\*******.default of your user folder.

It is an RDF file that connects mimetypes and file extensions to handlers and handlers to external applications. And whenever you download a file with a new mimetype, this mimetype is stored along with the extension of the file. If you chose to open the file with a given application and do so automatically in the future, this information will be stored as well.

Web-applications can send any mimetype they like, along with a file download. Most applications will send the correct mimetype or just omit it. But some applications send the incorrect or non-existing mimetypes mentioned above. And Firefox has no way of telling these apart as bogus.

Fortunately, Firefox doesn't just use mimeTypes.rdf, it first looks in a hardcoded override list, then in mimeTypes.rdf, then asks the OS [source].

Now, it also works the other way around: if you upload a file from your own filesystem to a website, Firefox checks mimeTypes.rdf to see which mimetype it should send. Since a mimetype may be connected with several extensions in mimeTypes.rdf, Firefox needs to choose. Some quick testing leads me to believe that it takes the first occurrance.

This problem is acknowledged by Firefox, mainly because it corrupts its internal handling of SVG files. [source]

What is the cause of the bug?

So Firefox is just being open and flexible. It can learn about filetypes it has never seen before and create new associations. But if you feed it garbage, it will spit out garbage. It works great for downloads, but it fails for uploads. It should keep its own mapping of file extensions and mimetypes and use this for uploads, or use mappings that are managed by the operating system. But it doesn't.

But why do web applications send corrupt mimetypes in the first place?
If an application needs to send a file to the browser, it first sends the HTTP headers that contain some meta information for the browser. Here's an example from PHP:

header('Content-Type: text/csv');
header('Content-Disposition: attachment; filename="data.csv"');

The first header tells the browser the mimetype, the second header the filename and disposition. The disposition can either be "inline" (the default: replace the current document in the same window) or "attachment" (open a file save dialog and ask the user what to do with the file).

This is the basic idea. And it works in all current browsers. However, it did not always work, for Internet Explorer 5.5, before SP1. The browser always opens certain mimetyped files (like text/html and text/plain) [source] inline. And the only way around this was to ... send a bogus mimetype, like application/download. Apparently the problem was fixed in 2000, but IE kept the reputation ever since, that it doesn't handle file attachments.

How should you determine the mimetype, then?

For the present, the damage is done. Too many web apps already use this technique and poison Firefox' mimeTypes.rdf. Even if Firefox fixes the bug, it will take a long time for all browsers to be updated. All we can do now is to ignore the browser mimetype as much as we can. There are several ways to do this. You can use more than one, and keep the most reliable mimetype.

  • Use your OS' mime detection software (in Linux, for example the file command file: file -i -b myfilename.ext)
  • Or use your application platform's mime detection software (in PHP, for example the PECL FileInfo extension)
  • Keep your own file extension -> mimetype mapping (usually your application handles only a limited amount of content types anyway and the content type can easily, though not safely be deduced from the file extension)
  • And if these don't succeed, keep the mimetype the browser suggested.

And how do you make sure the file is attached?

We want to corrupt the mimetype as little as possible, but we need to make sure it also works for IE 5.5 and before when downloading text/plain and text/html. An entry in tells us more. However, this solution by itself is the cause of all the problems.

But if we use this solution only for the case it is required (<= MSIE 5.5), we get the proposed workaround:

// select the right mimetype for your content, here we take text/csv as an example
$filename = 'mydata.csv';
$mimetype = 'text/csv';

// override the mimetype for IE <= 5.5
if (preg_match('/MSIE ([\d\.]*)/', $_SERVER['HTTP_USER_AGENT'], $matches)) {
    $version = $matches[1];
    $problematicMimes = array('text/plain', 'text/html');
    if (($version <= 5.5) && in_array($mimetype, $problematicMimes)) {
        $mimetype = 'application/download';

header('Content-Type: $mimetype');
header('Content-Disposition: attachment; filename="$filename"');

Final word

The mimetype is a very useful property for on-line content. It is used world-wide in a wide variety of fields. Therefore it is important that we make the extra effort to keep the standard strong.

For more information, see:

« Back

Reactions on "Mimetype corruption in Firefox"

John Giotta
Placed on: 01-28-2009 21:16
Is this only a problem with Firefox? I got the forced-download mime-type from an upload form through IE as well.
Placed on: 01-29-2009 13:16
Patrick van Bergen
User icon
to be continuum
Interesting, I have not heard of this before. What version of IE?
Placed on: 02-18-2009 10:48
The most interesting article I have ever read to describe the problem I try to deal with for days.
I tried to edit the mimeTypes.rdf file but it didn't work. So I deleted the file.
But how can we explain such a problem to end user ?
Placed on: 02-18-2009 16:52
Patrick van Bergen
User icon
to be continuum
"Mimetype" is a concept most end users have never heard of. Application developers will have to solve the problem before it hits their users. If solving the problem is out of your hands, you can only say to them that it's a Firefox bug.
Placed on: 04-24-2009 11:36
Excellent post! Really good description of an otherwise subtle problem.
Placed on: 05-18-2009 21:33
Thanks for this write up. It helped me make sense of a problem that our users were having when uploading PDFs to our site.

Creating a new FireFox profile ( helps to diagnose this issue for users.
Placed on: 06-20-2009 05:29
Good Post..Thanks a ton for the clear explanation..helps a lot.
Placed on: 03-20-2010 11:47
Thank you!
Placed on: 07-22-2010 22:49
Self explanatory, good article!

The solution I used was:

"Keep your own file extension -> mimetype mapping"
Placed on: 08-18-2012 11:09
I had the same problem uploading PDF-Files. Firefox sends application/x-octetstream an the mimetype. From my point of view a good solution is to look into the file in order to check whether it is an PDF or not. Most user don't know anything about mime types. Beeing flexible ist good but don't forget the end user. Such a behavior can bring a wrong light on an otherwise excelent program.

Log in to comment on news articles.