Resource interpreted as Document but transferred with MIME type application/zip

You can specify the HTML5 download attribute in your tag.

<a href="http://example.com/archive.zip" download>Export</a>

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a#attr-download

In your request header, you have sent Content-Type: text/html which means that you'd like to interpret the response as HTML. Now if even server send you PDF files, your browser tries to understand it as HTML. That's the problem. I'm searching to see what the reason could be. :)

I could not find anywhere just an explanation of the message by itself. Here is my interpretation.

As far as I understand, Chrome was expecting some material it could possibly display (a document), but it obtained something it could not display (or something it was told not to display).

This is both a question of how the document was declared at the HTML page level in href (see the download attribute in Roy's message) and how it is declared within the server's answer by the means of HTTP headers (in particular Content-Disposition). This is a question of contract, as opposed to hope and expectation.

To continue on Evan's way, I've experienced that:

Content-type: application/pdf
Content-disposition: attachment; filename=some.pdf

is just inconsistent with:

<a href='some.pdf'>

Chrome will cry Resource interpreted as document but transferred…

Actually, the attachment disposition just means this: the browser shall not interpret the link, but rather store it somewhere for other—hidden—purposes. Here above, either download is missing beside href, or Content-disposition must be removed from the headers. It depends on whether we want the browser to render the document or not.

Hope this helps.

I experienced this problem when serving up a PDF file (MIME type application/pdf) and solved it by setting the Content-Disposition header, e.g.:

Content-Disposition: attachment; filename=foo.pdf

Hope that helps.

I've fixed this…by simply opening a new tab.

Why it wasn't working I'm not entirely sure, but it could have something to do with how Chrome deals with multiple downloads on a page, perhaps it thought they were spam and just ignored them.

I had a similar issue when performing a file download through Javascript. Adding the download attribute made no difference but adding target='_blank' did - I no longer get the 'Resource interpreted as Document...' console message.

Here's my nicely simple code:

var link = document.createElement('a');
link.target = '_blank';
link.href = url;
document.body.appendChild(link); // Required for Firefox
link.click();
link.remove(); 

I haven't tried it with direct HTML but would expect it to work.

Note I discovered that Firefox requires the link to be appended to the document whereas Chrome will work without it.

I encountered this same issue today with Chrome Version 30.0.1599.66 with my node.js / express.js application.

The headers are correct, express sets them properly automatically, it works in other browsers as indicated, putting html 5 'download' attribute does not resolve, what did resolve it is going into the chrome advanced settings and checking the box "Ask where to save each file before downloading".

After that there was no "Resource interpreted as document...." error reported as in the title of this issue so it appears that our server code is correct, it's Chrome that is incorrectly reporting that error in the console when it's set to save files to a location automatically.

I encountered this when I assigned src="image_url" in an iframe. It seems that iframe interprets it as a document but it is not. That's why it displays a warning.

I solved the problem by adding target="_blank" to the link. With this, chrome opens a new tab and loads the PDF without warning even in responsive mode.

Just ran into this and none of the other information I could find helped: it was a stupid error: I was sending output to the browser before starting the file download. Surprisingly, I found no helpful errors found (like "headers already sent" etc.). Hopefully, this saves someone else some grief!

I had this issue in an ASP web site project. Adding a "Content-Length" header caused downloads to start working again in Chrome.

This issue was re-appeared at Chrome 61 version. But it seems it is fixed at Chrome 62.

I have a RewriteRule like below

RewriteRule ^/ShowGuide/?$ https://<website>/help.pdf [L,NC,R,QSA]

With Chrome 61, the PDF was not opening, in console it was showing the message

"Resource interpreted as Document but transferred with MIME type application/pdf: "

We tried to add mime type in the rewrite rule as below but it didn't help.

RewriteRule ^/ShowGuide/?$ https://<website>/help.pdf [L,NC,R,QSA, t:application/pdf]

I have updated my Chrome to latest 62 version and it started to showing the PDF again. But the message is still there in the console.

With all other browsers, it was/is working fine.

The problem

I had similar problem. Got message in js

Resource interpreted as Document but transferred with MIME type text/csv

But I also got message in chrome console

Mixed Content: The site at 'https://my-site/' was loaded over a secure connection, but the file at 'https://my-site/Download?id=99a50c7b' was redirected through an insecure connection. This file should be served over HTTPS. This download has been blocked

It says here that you need to use an secure connection (but scheme is https in message already, strangely...).

The problem is that href for file downloading builded on server side. And this href used http in my case.

The solution

So I changed scheme to https when build href for file downloading.

In my case the file name was too long, and got the same error. Once shortened below 200 chars worked fine. (limit might be 250?)

After a couple of csv file downloads (lots of tests) chrome asked whether to allow more downloads from this page. I just dismissed the window. After that chrome did not download the file any more but the console sayed:

"Resource interpreted as Document but transferred with MIME type text/csv"

I could solve that issue by restarting chrome (completely Ctrl-Shift-Q).

[Update] Not sure why this post was deleted but it provided the solution for me. I had gotten the message earlier about trying to download multiple files and must have answered no. I got the "Resource interpreted..." message until I restarted the browser; then it worked perfectly. For some cases, this may be the right answer.

I got this error because I was serving from my file system. Once I started with a http server chrome could figure it out.

I was experiencing the same trouble with a download manager I created. The problem I was having involved the file name being too long and the extension being clipped off.

Example: File Name : Organizational Protocols and Other Things That are Important.pd

<?php
  header("Content-Disposition: attachment; filename=$File_Name");
?>

Solution: Increased the MySQL database field to 255 to store the file name, and performed a length check before saving the blob. If the length > 255 trim it down to 250 and add the file extension.

Try below code and I hope this will work for you.

var Interval = setInterval(function () {
                if (ReportViewer) {
                    ReportViewer.prototype.PrintReport = function () {
                        switch (this.defaultPrintFormat) {
                            case "Default":
                                this.DefaultPrint();
                                break;
                            case "PDF":
                                this.PrintAs("PDF");
                                previewFrame = document.getElementById(this.previewFrameID);
                                previewFrame.onload = function () { previewFrame.contentDocument.execCommand("print", true, null); }
                                break;
                        }
                    };
                    clearInterval(Interval);
                }
            }, 1000);

I've faced this today, and my issue was that my Content-Disposition tag was wrongly set. It looks like for both pdf & application/x-zip-compressed, you're supposed to set it to inline instead of attachment.

So to set your header, Java code would look like this:

...
String fileName = "myFileName.zip";
String contentDisposition = "attachment";
if ("application/pdf".equals(contentType)
    || "application/x-zip-compressed".equals(contentType)) {
    contentDisposition = "inline";
}
response.addHeader("Content-Disposition", contentDisposition + "; filename=\"" + fileName + "\"");
...

The problem

I literally quote Saeed Neamati (https://stackoverflow.com/a/6587434/760777):

In your request header, you have sent Content-Type: text/html which means that you'd like to interpret the response as HTML. Now if even server send you PDF files, your browser tries to understand it as HTML.

The solution

Send the bloody correct header. Send the correct mime type of the file. Period!

How?

Aaah. That totally depends on what you are doing (OS, language).

My problem was with a dynamically created download link in javascript. The link is for downloading an mp3 file. An mp3 file is not a document, neither is a pdf, a zip file, a flac file and the list goes on.

So I created the link like this:

and I changed it to this:

Problem solved. Adding an extra attribute to the form tag solved it. But there is no generic solution. There are many different scenario's. When you send a file from the server (you created it dynamically with a language like CX#, Java, PHP), you have to send the correct header(s) with it.

Side note: And be careful not to send anything (text!) before you send your header(s).

I got the same error, the solution was to put the attribute

target = "_ blank"

Finally :

<a href="/uploads/file.*" target="_blank">Download</a>

Where * is the extension of your file to download.