Resource interpreted as image but transferred with MIME type text/html - Magento

Question

I'm getting below error when uploading a new product image for my Magento shop.

Resource interpreted as image but transferred with MIME type text/html

Is there a reason why this is happening?

Duplicate, see http://stackoverflow.com/questions/1386312/resource-interpreted-as-other-but-transferred-with-mime-type-text-javascript — Neil, May 30 '12 at 03:47
@Neil Not quite a dupe; OP got a different mime type than the other question. — BryanH, Dec 03 '12 at 17:28
In my situation image is like `data:image;base64,/9j/4AAQS.....` And in Chrome seems it is not as error. Seems as warning. And the warning is because i must set/write file type after `data:image` — Andris, Feb 15 '15 at 07:56

score 45 · Answer 1 · answered Jan 09 '13 at 11:58

45

This might well occur if your image path is set incorrectly. For example relative to current directory "images/myimage.gif" vs relative to web root "/images/myimage.gif".

The reference to "text/html" might suggest you have an error being returned by the server.

answered Jan 09 '13 at 11:58

Ian Lewis

1,311
13
18

This should be marked as the best answer IMO - thanks – hardba11 Jul 23 '14 at 19:04
yeah in my case it was S instead of a small s :P – Faizan Jan 11 '15 at 19:38

score 12 · Answer 2 · answered Feb 09 '13 at 21:33

12

I noticed this problem appearing in my JavaScript Console log. It was a simple case of a CSS file looking for a background image that didn't exist and the server sending a 404 error message in its place.

answered Feb 09 '13 at 21:33

stevecomrie

2,423
20
28

Martin Zeitler · Answer 3 · 2014-01-24T02:02:15.443

5

One needs to serve the images with the proper MIME type -

Add this line into the .htaccess file (assuming it's apache2 httpd):

AddType image/gif .gif

hint: mod_rewrite might require an exclusion for images:

RewriteCond %{REQUEST_URI} !\.(png|gif|jpg)$
RewriteRule ...

... everything else might be 404 indeed.

edited Jan 24 '14 at 02:02

answered Jan 24 '14 at 01:22

Martin Zeitler

1
19
155
216

score 3 · Answer 4 · answered Oct 16 '13 at 15:57

I had the same problem once, because of capitalization.

My Colleagues were working on a Mac and added some camel-cased files, but it showed up lowercased in CSS. This works fine on Mac, but I was working on Linux. Mac doesn't distinguish filenames having different cases but Linux does. Most servers out there run on Linux.

example:

epicimage.jpg !== EpicImage.jpg

Thanks to the Chrome Dev Tools, the problem could be found very easy. Simply clicking on the image url showed me our 404 page. Mystery solved :D

score 3 · Answer 5 · answered Jun 29 '14 at 13:21

3

Please check extension of your image, whether the program used create the image labels its extension with capital letters or small letters, some servers read them different.

answered Jun 29 '14 at 13:21

Raphael Amponsah

549
6
13

2

+1, changing ".JPG" to ".jpg" fixed the issue for me. – Emmanuel M. Smith Jul 07 '14 at 15:17

score 2 · Answer 6 · answered Dec 20 '12 at 12:40

I checked out basically every similar question on StackOverflow trying to solve a similar issue.

After all the attempts at altering my htaccess file and inserting php head arguments, what fixed it for me was ...just changing the capitalization on the picture's name.

Ugh. (It was working fine in the same browser local-hosted, too... so of course I wouldn't think that was the issue initially.)

score 2 · Answer 7 · answered Apr 15 '13 at 03:27

After a lot of research, I have found the problem is caused by a combination of things resulting in the server not knowing what type of document it is and getting mixed up between encoding types such as UTF-8 (or something like that)

So, in .htaccess, change the comments round so you have the following, giving a default character set of UTF-8.

############################################
## Prevent character encoding issues from server overrides
## If you still have problems, use the second line instead

    #AddDefaultCharset Off
    AddDefaultCharset UTF-8

This stopped the correct error shown in google (thank you mr google): "resource interpreted as image but transferred with mime type text/html"

And the made the images show up in other browsers (where there was no error shown).

score 2 · Answer 8 · answered Mar 13 '15 at 16:17

2

My issue was with this line in the CSS

background-image: url('');

Which should have been:

background-image: none;

answered Mar 13 '15 at 16:17

Strixy

568
5
15

score 0 · Answer 9 · answered Jan 15 '14 at 17:04

For me my path was set incorrectly relative to the css file that was trying to pull the image from that triggered the error in the console.

I had to go out 2 directories and then into the one that had my image.The .. before the slash brings you out of a directory. Each . brings you out one more directory.

ex. url (../Folder/ImagesFolder/image.gif)

score 0 · Answer 10 · answered Nov 11 '14 at 18:43

0

If your image path and case-sensitive filename is set correctly, and if you can't modify your server's .htaccess file, encoding the SVG as a data URI is a front-end solution. css-tricks.com explains how: http://css-tricks.com/using-svg/

answered Nov 11 '14 at 18:43

matbergman

43
5

score 0 · Answer 11 · answered Apr 21 '15 at 18:35

0

This happened with me when I was including SVG image via img tag. If you are including SVG image via tag you need to switch to Object tag instead: <object type="image/svg+xml" data="imageFile.svg"> Test SVG Logo </object>

answered Apr 21 '15 at 18:35

TechMaze

477
2
9

score 0 · Answer 12 · edited May 23 '17 at 12:06

For me, this mime type error showed only when testing Safari 4.05 per client requirements, and only in the console. Ultimately this was caused by Safari handling the javascript styling element.style.backgroundImage="url()"; ungracefully. Evidently, Safari was looking for that empty url, so per Strixy and stevecomrie, "none" is the better choice. This is essentially the same issue as noted above as near duplicate of Resource interpreted as other but transferred with MIME type text/javascript?, wherein a <script src=""> was the culprit.

score 0 · Answer 13 · answered May 04 '16 at 10:20

For magento2 Users

If you have modified this file app/etc/di.xml with following

<item name="view_preprocessed" xsi:type="object">Magento\Framework\App\View\Asset\MaterializationStrategy\Copy</item>

make sure the path string is Case Sensitive (CaseSensitive for non Windows OS)

If you are facing 404 errors after magento2 Install in Ubuntu.

Install and Enable rewrite module

a2enmod rewrite

Then Edit

 /etc/apache2/sites-available/000-default.conf

Add following lines at the End

<Directory "/var/www/html">
    AllowOverride All 
</Directory>

score 0 · Answer 14 · answered May 10 '16 at 03:42

0

Maybe images didn't have read permission

I also got this problem, when i use TinyPNG to compress images, i got this error message "Resource interpreted as Image but transferred with MIME type text/html". Then i add images permission, it works.

answered May 10 '16 at 03:42

weimin

41
5

score -2 · Answer 15 · answered Nov 09 '11 at 08:31

-2

image is sent with wrong headers, add headers to image type via .htaccess

answered Nov 09 '11 at 08:31

Anton S

12,750
2
35
37

MIME types set what a file is, or rather what file extensions refer to what file types. For example, a '.html' file extension refers to a HTML document, a '.zip' file extension refers to a ZIP archive file. The server needs to know this so it knows how to deal with the file. – Anton S Jul 26 '12 at 13:11

Resource interpreted as image but transferred with MIME type text/html - Magento

15 Answers15

Linked