MIME type ('text/html') not a supported stylesheet MIME type

I’m using Trellis with Bedrock and Sage 9.0 and I can’t get past this error.

Refused to apply style from 'http://localhost:3000/app/themes/twinllamas/dist/styles/main.css' because its MIME type ('text/html') is not a supported stylesheet MIME type, and strict MIME checking is enabled

It loads fine from the url I’ve set, but not from localhost. Is there a way to get this working with Sages’s yarn processes? It works if I run yarn build but not yarn run start


Where is this error coming from exactly?

I am seeing this error for the first time. Maybe an update to google chrome? That was my first thought and reaction although I am not sure.

This exact error, for me, was in google chrome Version 64.0.3282.167 on a Mac. It was in the browser’s error console.

I get it in the console in Google Chrome. I don’t know what in nginx might be causing it, but I see the error in Chrome.

I get the same console error in Chrome as well. My virtualhost will not load styles so I’m only seeing the unstyled render. Localhost works as intended after running yarn start.

Do you see your stylesheet when you go to http://localhost:3000/app/themes/twinllamas/dist/styles/main.css? Google search suggests that many people with this error are seeing it because that URL is actually returning an error page, not a stylesheet.


I get a 404 when I try to view it because the server refuses to send it. I have confirmed that my stylesheet does exist in my dist folder though.

The browser will always return a 404 for style.css when you run yarn start because it uses webpack to inject styles directly into the page. The file in your dist folder is probably one left over from running yarn build. The specific error you’re seeing seems new. This workaround may work for you: https://github.com/roots/sage/issues/1826

Some other discussions:


Just got the same error but with Sage 8…

It’s honestly really frustrating. I wanted to get into Trellis, but as a solo developer I don’t have days on end to wait for a solution.

I ran yarn build before yarn start. Maybe I’m crazy but it’s not that the file doesn’t exist. It’s that the server is serving the stylesheet as wrong MIME type. If I was using a different theme or product, I’d understand, but I expect Trellis, Bedrock and Roots to play nicely together out of the box.

We all do our best to respond to support threads as our time and expertise allows. As I’m sure you understand, we all have day-jobs as well which can sometimes keep us away from the forum for longer than we’d wish.

To your problem, reviewing this thread…

  • I see that the problem appears in Chrome --does it appear in other browsers as well?
  • Have you tried destroying and re-creating your Trellis VM?
  • Another user mentions the problem on a Mac, but I don’t see where you’ve indicated a platform. Are you also on a Mac?
  • Have you tried another theme? If Trellis has a MIME type problem with Sage’s .css files, then other themes should show the same problem.

We hope we can help you nail down this issue. Thanks for working with us.


We’re experiencing the same issue, so I’ll try to answer these questions.

I see that the problem appears in Chrome --does it appear in other browsers as well?
Having the same issues in Chrome (version 64.0.3282.186) and Safari (version 11.0.3). Safari gives a different error message, saying that the file doesnt exist:
Failed to load resource: the server responded with a status of 404 (Not Found)

Have you tried destroying and re-creating your Trellis VM?
Yes, It didn’t help.

Are you also on a Mac?
Yes, macOS High Sierra 10.13.3.

Have you tried another theme?
I threw in Html5blank and I do not get the same error.

Okay, first and most importantly:

Error messages about main.css while running yarn start (or yarn run start) are normal, expected, and by design.

This happens because main.css actually doesn’t exist while running yarn start. Instead, styles are built in memory and injected into the page by Webpack. Errors related to main.css in the browser console can and should be safely ignored while running yarn start.

If you are running yarn start and your page/site looks unstyled in the browser

This can happen sometimes. It’s inconsistent and seems to have something to do with the imperfect software that “shares” your local theme development directory with the Vagrant box. You can fix it either by making a change to, and saving, any .scss file, or hard-refreshing the page (with SHIFT+Refresh), or sometimes both.

If the missing main.css file message persists after running yarn build or yarn build:production

Make sure you’re not refreshing your page WHILE the yarn task is running. Sage versions its assets and browsers are really reluctant to give up on caches of stylesheets. Let yarn finish its task, wait a beat, and then refresh your browser.

Let us know if any of that helps.


Woops, it would seem that my previous post isn’t valid. I’m now getting this error consistently. I’ve tracked this down to yarn dependancies as existing projects which have cached dependancies on a different machine work fine. This is a Sage / WebPack issue specifically. Unfortunately I don’t have time to investigate this deeper today, but crudely copying node_modules from another project pre February works for me.

I’ll try to find some time later in the week to provide anymore information


Also seeing this in Chrome 65 using Trellis + Bedrock + Sage 9.


So after a lot of trial and error and comparing some projects with the very useful Mac app Kaleidoscope I’ve managed to track this down to a Trellis issue as first assumed. Or at least the HBP5 dependancy paired with a Chrome update


The issue lies in the extra security directives applied by the HBP5 nginx configuration. This is included in Trellis here:

Looking at the HBP5 config file you can see that only CSS from the same source is trusted by a Content-Security-Policy directive here:

Recent security updates to webkit browsers (Safari / Chrome) mean that although these settings have been lying dormant for a while in the HBP5 directives they’ve only just started being applied with the recent releases of browsers. Combined with updates of Trellis.

How to reproduce

  • Latest version of the roots stack
  • Latest version of Chrome / Chrome Beta
  • Run yarn run start - issue will occur as localhost:3000 is not seen as the same domain as your site URL


As we don’t need this in our development environment I’d suggest that we disable the HBP5 extra security directives on development.

Change highlighted line from


# Only apply extra security outside dev to avoid proxy CSP issues
{% if h5bp_extra_security_enabled and not_dev -%}
include h5bp/directive-only/extra-security.conf;
{% endif -%}

The not_dev helper is already configured here:

Although @swalkinshaw may have some better solutions? My concern about this condition is that it will undo environment parity and may cause more issues in the support forum. If you’d like a hand with this Scott I’d love to raise my first PR if you can offer your thoughts on this proposed fix?

Important After applying the above fix you should run a vagrant provision in your affected projects. Also be mindful that this would mean you won’t be aware of similar CSP issues in your development environment yet they may appear on staging / production

EDIT As per comments below the root of this issue doesn’t appear to be CSP related, however the fix provided does still work

cc @krishaamer, @davidohlin, @builtbyvern, @mikesource, @asuh, @rmendoza


At this first this appeared promising, but the line in the extra-security config you linked is commented out.

I just checked on a brand new Vagrant/Trellis provision and that line is commented out too:

# The X-Frame-Options header indicates whether a browser should be allowed
# to render a page within a frame or iframe.
add_header X-Frame-Options SAMEORIGIN always;

# MIME type sniffing security protection
#       There are very few edge cases where you wouldn't want this enabled.
add_header X-Content-Type-Options nosniff always;

# The X-XSS-Protection header is used by Internet Explorer version 8+
# The header instructs IE to enable its inbuilt anti-cross-site scripting filter.
add_header X-XSS-Protection "1; mode=block" always;

# with Content Security Policy (CSP) enabled (and a browser that supports it (http://caniuse.com/#feat=contentsecuritypolicy),
# you can tell the browser that it can only download content from the domains you explicitly allow
# CSP can be quite difficult to configure, and cause real issues if you get it wrong
# There is website that helps you generate a policy here http://cspisawesome.com/
# add_header Content-Security-Policy "default-src 'self'; style-src 'self' 'unsafe-inline'; script-src 'self' https://www.google-analytics.com;" always;

Note the last line starts with #.

CSP also has very specific and explicit errors. It would say it’s denied due to CSP, not a Mime type error.

This could potentially be this line:

add_header X-Content-Type-Options nosniff always;

Apologies it’s late here in the UK (4am)

If you run a test locally you’ll see the errors stop in Chrome / Safari. I’ve tried this on existing projects and new. Admittedly my reference to CSP is sleep deprived me getting all excited about fixing something :wink:


Thanks for your deep research! I was also running into this error (mainly in Chrome, but later also in Safari) and couldn’t figure out what was going on.

I ssh’d into my Vagrant box and commented out the line:

add_header X-Content-Type-Options nosniff always;

in: /etc/nginx/h5bp/directive-only/extra-security.conf

And I can confirm the error disappears in Chrome & Safari!
Nice work :slight_smile: