The error “Refused to apply style because its MIME type (‘text/html’) is not a supported stylesheet MIME type, and strict MIME checking is enabled” stops your browser from applying a CSS file to a webpage. The browser asked the server for a stylesheet, the server returned an HTML document instead, and the browser — following strict MIME type enforcement — refused to process it as CSS. The result is a webpage with no styling: raw unstyled text, broken layouts, and none of the visual structure visitors expect.

This error appears in the browser’s developer console and causes immediate visual breakage. On WordPress sites it is one of the most confusing errors developers encounter because the CSS files are genuinely present on the server — the issue is not a missing file but a miscommunication between how the resource is requested and what the server returns. Understanding what the browser is actually telling you changes everything about how to diagnose and resolve it quickly.

This guide walks through every verified cause and the specific fixes for each, starting with the fastest diagnosis steps that resolve 95% of cases within minutes, then covering server configuration fixes, WordPress-specific solutions, CDN issues, and prevention strategies for keeping the error from returning.

What Does This Error Actually Mean?

MIME stands for Multipurpose Internet Mail Extensions — the system that tells browsers what type of content they’re receiving. When a browser loads a webpage, it sends HTTP requests for each linked resource: images, scripts, and stylesheets. Each resource request returns a response header that includes a Content-Type field, which declares the file type. For a CSS file, that header must read Content-Type: text/css.

When the browser receives Content-Type: text/html for a resource linked as a stylesheet, it means the server returned a webpage — typically a 404 Not Found error page or a server error page — instead of the CSS file that was requested. Modern browsers with the X-Content-Type-Options: nosniff header active enforce this check strictly, refusing to execute or apply any resource where the declared MIME type doesn’t match its expected use.

The error message is the browser being precise: it is not saying the CSS file is corrupt or invalid. It is saying the resource it received was declared as HTML, and it will not use an HTML document as a stylesheet. The underlying problem is almost always that the correct CSS file was never delivered — either because the path is wrong, the server is misconfigured, a caching layer is serving a stale error page, or a WordPress process that generates CSS dynamically failed to complete.

How to Diagnose the Error in 60 Seconds

Open the browser’s developer tools (F12 in Chrome, Firefox, or Edge), navigate to the Network tab, and reload the page. Filter by “CSS” using the filter bar at the top of the Network panel. Find the stylesheet that triggered the console error — it will appear in red or with a 4xx/5xx status code — and click on it to inspect the response headers.

The Response Headers section shows the actual Content-Type returned by the server. If it reads text/html, the server returned an error page. Copy the URL from the Request URL field and paste it directly into a new browser tab. What loads in that tab is exactly what the server is returning when asked for that CSS file. If a 404 page, a login screen, an error message, or any HTML content loads instead of raw CSS code, the cause of the error is immediately visible.

This single diagnostic step — viewing the CSS URL directly in a browser tab — resolves the ambiguity immediately. A 404 means the file path is wrong or the file is missing. A login page means authentication is blocking access. A blank page or partial CSS means a WordPress dynamic stylesheet generation process failed. A full styled 404 error page from a CDN means the CDN is caching a previous error state for that URL.

How to Fix the MIME Type Error: Step-by-Step Solutions

Check the CSS URL for a 404 error first: Navigate to the reported stylesheet URL directly in a new browser tab. If a 404 page loads, the problem is a broken file path — not a MIME type configuration issue. Address this before any server-side changes, because server configuration is irrelevant when the file simply is not at the requested location.
Flush WordPress permalinks: Go to WordPress Admin → Settings → Permalinks and click Save Changes without changing any settings. This regenerates the .htaccess rewrite rules, which WordPress uses to route requests for dynamically-generated CSS files. A corrupted or missing rewrite rule sends CSS requests to WordPress’s main index, which returns HTML — exactly the MIME type mismatch the browser reports. Flushing permalinks resolves this class of error in the majority of cases.
Disable WordPress debug mode in wp-config.php: Open wp-config.php and locate any of these constants: WP_DEBUG, WP_DEBUG_LOG, WP_DEBUG_DISPLAY, and SCRIPT_DEBUG. Set each to false or remove the lines entirely. When debug mode is active, PHP notices and warnings are output directly into response streams — including into dynamically generated CSS files. This corrupts the CSS output with HTML-formatted debug text, causing browsers to classify the file as text/html instead of text/css.
Clear all caches — completely: Clear your caching plugin’s object cache and page cache, flush the CDN cache if one is active, clear your server’s opcode cache if accessible, clear the browser cache, and if using a theme with its own cache (Elementor, Divi, Avada, Beaver Builder), clear the theme’s CSS regeneration cache specifically. A cached version of a 404 response for a stylesheet URL means every visitor continues to receive the MIME type error even after the underlying problem has been fixed. The cache must be cleared at every layer to let the corrected resource propagate.
Fix the file path in the <link> tag or enqueue function: For custom themes and child themes, verify the stylesheet path in the HTML <link> tag or the wp_enqueue_style() function matches the actual file location. Common mistakes include missing the .min extension on minified stylesheets, an incorrect subdirectory reference, or a hardcoded domain that doesn’t match the current environment. Use get_stylesheet_directory_uri() and get_template_directory_uri() instead of hardcoded paths to prevent environment-specific path breakage.
Add MIME type declaration to .htaccess (Apache servers): On Apache-based hosting, open the root .htaccess file and add the following directive to force the correct MIME type for CSS files:
AddType text/css .css
Place this within the <IfModule mod_mime.c> block if one exists, or add it to the top of the file. This forces Apache to declare text/css as the Content-Type for any file with a .css extension, overriding any server-level misconfiguration.
Verify MIME type configuration on Nginx servers: On Nginx, open the configuration file at /etc/nginx/mime.types and confirm the following line is present: text/css css;. Also verify that your server block includes the directive include mime.types; within the http block. Without this include, the MIME types file is ignored even if the entry for CSS is correct. Restart Nginx after any changes to apply the configuration.
Resolve HTTP/HTTPS protocol mismatches: A stylesheet URL beginning with http:// on a site served over HTTPS is blocked by mixed content policies in addition to potentially triggering MIME type errors if the request gets redirected to an error page. Run a search-and-replace in the WordPress database to update all resource URLs from http:// to https://. Use the Better Search Replace plugin for a safe, reversible database operation, or the WP-CLI command wp search-replace 'http://yourdomain.com' 'https://yourdomain.com' --all-tables.
Deactivate plugins one by one to isolate a conflict: Security plugins, firewall plugins, and some optimization plugins intercept CSS requests and can return authentication challenges or error pages with HTML content type. Deactivate all plugins via the WordPress admin panel, then reload the page and check if the error clears. If it does, reactivate plugins one at a time to identify the conflicting plugin. Pay particular attention to security plugins (Wordfence, iThemes Security), optimization plugins, and any plugin that processes static assets.
Purge CDN cache and check CDN configuration: If using Cloudflare, BunnyCDN, or another CDN, a cached error response for a CSS URL persists until the CDN cache is explicitly purged. Log in to the CDN dashboard and perform a full cache purge or purge only the affected CSS URL. Also verify the CDN’s Page Rules are not rewriting or redirecting CSS file requests in a way that modifies the Content-Type header. Cloudflare’s “Minify” settings for CSS can occasionally interfere with dynamically-generated stylesheets — disable CSS minification in Cloudflare if the error persists after flushing.

WordPress-Specific Causes and Targeted Fixes

WordPress generates some CSS files dynamically through PHP rather than serving static files. The Customizer’s Additional CSS, child theme stylesheets loaded through wp-enqueue-scripts, and CSS output from page builders like Elementor, Beaver Builder, and Divi are all generated at request time. When a PHP error, a file permission problem, or a corrupted transient cache interrupts this generation process, WordPress outputs an error page with a text/html content type instead of the expected CSS.

File permission errors are a common silent cause. The WordPress process needs write permission to generate and save dynamic CSS files to the wp-content/uploads/ directory or to a theme’s cache directory. If these permissions are set too restrictively — common after a server migration or a manual file upload — the CSS generation fails and the request returns a PHP error wrapped in HTML. Correct permissions are typically 755 for directories and 644 for files. Verify and correct permissions via FTP, SSH, or your hosting panel’s file manager.

After a domain migration or staging-to-production push, URLs stored in the WordPress database still reference the old domain or the staging URL. WordPress stores stylesheet paths in wp_options table entries for siteurl and home, as well as in serialized option values for theme settings and page builder configurations. CSS requests built from these stale URLs either 404 or hit the wrong server — both return HTML. Running Better Search Replace to update all old URLs to the correct production domain resolves this class of issue completely.

What Causes This Error in Non-WordPress Environments

Outside WordPress, the same MIME type error occurs in Node.js/Express applications when custom route handlers respond to CSS file requests before the static file middleware can serve them. The static file middleware must be declared before any catch-all routes: app.use(express.static(__dirname + '/public')) placed after a wildcard route handler causes every CSS request to be processed by the route handler first, which returns HTML. Moving the static middleware declaration above all route handlers resolves this ordering problem.

In React, Vue, and Angular development environments, the error typically means the development server’s public directory is misconfigured. A stylesheet referenced in the HTML template with an incorrect base path receives a 404 from the dev server, which serves the index.html fallback for unknown routes as part of client-side routing support. The fix is aligning the stylesheet path with the correct public URL base — either correcting the href attribute or adjusting the build tool’s publicPath configuration to match where static assets are actually served.

For projects deployed to AWS S3 or Google Cloud Storage, static CSS files uploaded without explicit content type metadata are stored with a generic application/octet-stream or text/plain MIME type rather than text/css. The browser receives the incorrect content type declaration and triggers the MIME type error even though the CSS file content itself is valid. Fix this by re-uploading the CSS file with an explicit content type flag: on AWS S3, add --content-type='text/css' to the upload command; on Google Cloud Storage, use -h 'Content-Type:text/css'.

Preventing the Error from Returning

Establishing a staging environment that mirrors production server configuration prevents the most common class of MIME type errors: environment-specific path mismatches that only appear after deployment. A staging site with identical server software, the same MIME type configuration, and the same directory structure surfaces stylesheet loading problems before they reach production visitors. Most managed WordPress hosting providers (Kinsta, WP Engine, SiteGround) include staging environments as standard features.

Monitoring CSS resource delivery as part of a regular performance audit catches MIME type issues before they become production incidents. Browser developer tools, GTmetrix, and WebPageTest all show the content type returned for each resource in their waterfall reports. Running a monthly performance check that includes inspecting response headers for critical stylesheets costs 10 minutes and catches server configuration drift before it breaks anything.

Version-controlled deployments reduce the risk of introducing path mismatches during theme or plugin updates. Tracking theme files in Git means any change to stylesheet paths, enqueue functions, or directory structure is documented, reversible, and visible in the diff before the change is deployed. Accidental typos in file paths — one of the most common causes of this error — become immediately visible in the pull request review rather than discovered as a production CSS outage.

Top 10 WordPress Tools to Diagnose and Fix Resource Loading Errors

These tools were selected for their direct relevance to diagnosing, fixing, and preventing the CSS MIME type error and similar resource loading failures. The list covers free diagnostic plugins, caching tools that manage CSS file generation, performance monitoring services, and URL management utilities. Every pricing figure below was confirmed from official sources during research for this article.

Query Monitor — Best Free WordPress Debugging Plugin

Query Monitor is the most comprehensive free debugging plugin available for WordPress and the first tool to install when diagnosing resource loading errors. It adds a persistent admin toolbar to every page load showing database queries, PHP errors, hooks, conditionals, HTTP API calls, and enqueued scripts and styles — including the exact path and handle for every stylesheet registered via wp_enqueue_style(). When a CSS file is enqueued with a wrong path, Query Monitor shows the incorrect URL alongside the PHP file and line number that registered it, eliminating the guesswork from path debugging. The plugin is completely free with no premium tier.

FREE — no paid tier
Shows all enqueued stylesheets with file paths and handles
Displays PHP errors and notices in the admin bar
HTTP API request log identifies failed external CSS requests
100,000+ active installations on WordPress.org

Query Monitor’s output is only visible to logged-in WordPress administrators, making it safe to run on production sites without exposing debug information to visitors. The weakness is that it requires administrator access to be useful — debugging stylesheet loading for non-logged-in visitors requires temporarily enabling WP_DEBUG or capturing the issue through server logs, which Query Monitor cannot access directly.

Health Check & Troubleshooting — Best for Plugin Conflict Isolation

The Health Check & Troubleshooting plugin is the official WordPress tool for isolating plugin and theme conflicts without disabling anything for live visitors. Its Troubleshooting Mode activates a clean WordPress environment — default theme, no plugins — visible only to the logged-in administrator, while the site continues to run normally for everyone else. This feature makes it the safest way to test whether the MIME type error is caused by a specific plugin, because the process never touches the live user experience. The plugin also runs a full site health check that flags known configuration issues, including permalink structure problems that cause resource loading failures. It is completely free.

FREE — official WordPress plugin
Troubleshooting Mode isolates conflicts without affecting live visitors
Site Health Check flags permalink and configuration issues
Tests individual plugin deactivation safely in admin session
Maintained by the WordPress core team

Troubleshooting Mode only tests the admin session — it cannot replicate the exact conditions of a logged-out visitor’s experience in all cases. Some MIME type errors tied to caching systems or CDN behavior require purging the cache even during Troubleshooting Mode testing to produce accurate results.

Better Search Replace — Best Database URL Migration Tool

Better Search Replace handles the most common post-migration cause of MIME type errors: stale domain references in the WordPress database. After a domain migration or staging-to-production push, stylesheet paths stored in serialized option values still point to the old domain. Better Search Replace performs safe search-and-replace operations across all database tables, handles serialized data correctly without corrupting it, and supports dry runs that show what would change before committing. The free version handles all standard migration scenarios. The PRO version adds multisite support, regex search, and the ability to replace values selectively by table. PRO pricing starts at $39 per year for a single site license from the Delicious Brains store.

Free version covers single-site domain migrations
PRO from $39/year with multisite and regex support
Safe serialized data handling prevents database corruption
Dry run mode previews changes before execution
Supports all WordPress database tables including custom tables

Better Search Replace does not back up the database before running — always export a database backup manually before executing any search-and-replace operation, particularly on production sites. The plugin does not handle file paths outside the database, so CSS files with hardcoded paths in PHP template files must still be corrected manually.

WP Rocket — Best Premium Caching Plugin for CSS Management

WP Rocket is the most widely deployed premium caching plugin for WordPress and the one that resolves the largest category of CSS-related MIME type errors: stale or corrupted cached CSS files. Its CSS minification and combination features generate optimized CSS files and store them in wp-content/cache/min/ with correct text/css content types when properly configured. The plugin’s “Clear Cache” button regenerates all cached CSS files instantly — the fastest way to clear a cached error response for a stylesheet when the MIME type error appeared after a plugin or theme update. Single site licensing costs $59.95 per year, with a Plus plan at $119.95 per year for three sites and a Multi plan at $299.95 per year for fifty sites. A 14-day money-back guarantee is included.

Single site: $59.95/year (regularly; currently $44.96/year on sale)
Plus plan: $119.95/year for 3 sites
Multi plan: $299.95/year for 50 sites
One-click full cache clear including CSS files
CSS minification and combination with correct MIME type output

WP Rocket’s CSS optimization features — particularly CSS file combination — can introduce their own MIME type errors if the combined file URL conflicts with a security plugin’s access rules or a CDN’s caching configuration. Disabling CSS combination while keeping general page caching active resolves this category of WP Rocket-induced MIME type issues, which affect a minority of installations but confuse developers who expect the caching plugin to be part of the solution rather than the cause.

LiteSpeed Cache — Best Free Caching Plugin for LiteSpeed Servers

LiteSpeed Cache provides server-level caching integration for WordPress sites hosted on LiteSpeed Web Server — a setup that includes most Hostinger, A2 Hosting, and CloudLinux-based shared hosting environments. The plugin manages CSS file caching at the server level with correct MIME type handling by default, and its “Flush All” button clears every cached resource including CSS files in a single action. For diagnosing MIME type errors on LiteSpeed-hosted WordPress sites, clearing the LiteSpeed Cache is the correct first step before any server configuration changes. The plugin is completely free, including all CSS optimization, critical CSS generation, and image optimization features.

FREE — all features included at no cost
Server-level CSS caching with correct MIME type enforcement
Critical CSS generation reduces initial stylesheet load
Flush All option clears CSS cache in one click
Requires LiteSpeed or OpenLiteSpeed web server for full functionality

LiteSpeed Cache’s full feature set is only available on LiteSpeed Web Server — Apache and Nginx installations cannot use server-level caching features, though page caching through WordPress object caching still works. Teams on Apache hosting expecting LiteSpeed Cache to deliver its full optimization suite will find the plugin significantly limited compared to its LiteSpeed-native behavior.

GTmetrix — Best External Resource Loading Auditor

GTmetrix provides an external, server-independent view of exactly what happens when a page loads — including the content types returned for every CSS file, the response codes, load timing, and the full HTTP waterfall. When diagnosing a MIME type error that only occurs for some visitors (common with CDN caching that varies by edge node), GTmetrix tests from multiple geographic locations and multiple test times, making it possible to observe whether the error is intermittent or consistent. The free tier allows on-demand tests from a single location. Paid plans start at $4.99 per month (Lite, billed annually) for 50 on-demand tests per month and expand to $9.99 per month (Core) for 150 tests and 10 test locations, and $24.99 per month (Advanced) for unlimited tests and 28 global test locations.

Free tier: on-demand tests from one location
Lite: $4.99/month annually — 50 tests, 5 locations
Core: $9.99/month annually — 150 tests, 10 locations
Advanced: $24.99/month — unlimited tests, 28 locations
Full HTTP waterfall shows content type per resource

GTmetrix’s test results show what an external server receives, not what a logged-in administrator experiences — this makes it the accurate view for testing MIME type errors as a regular visitor would encounter them. The weakness is that GTmetrix cannot log in to test authenticated sessions, and some caching setups serve different content to logged-in users versus anonymous visitors, requiring complementary diagnostic approaches for those configurations.

W3 Total Cache — Best Free Full-Stack Caching for Apache Servers

W3 Total Cache is the longest-standing free full-stack caching plugin for WordPress and the most feature-complete free option for diagnosing and resolving cache-related MIME type errors on Apache-based hosting. Its browser cache settings control the Content-Type headers that WordPress declares for cached resources — a misconfigured browser cache setting in W3 Total Cache can cause CSS files to be served with incorrect MIME types even when the underlying files are correct. The plugin’s “Empty All Caches” button is the starting point for any MIME type error diagnosis on a site running W3 Total Cache. The plugin is free with optional paid CDN add-ons through the Stackpath CDN integration.

FREE — all core caching features included
Controls browser cache headers including Content-Type declarations
Database, object, page, and browser cache in one plugin
Apache and Nginx configuration export for server-level rules
Optional Stackpath CDN integration available as paid add-on

W3 Total Cache has a significantly more complex configuration interface than newer alternatives like WP Rocket or LiteSpeed Cache. Misconfigured settings — particularly in the browser cache and CDN sections — can introduce MIME type errors rather than prevent them. Sites without a developer comfortable with caching concepts often achieve better results with a simpler tool.

Autoptimize — Best Free CSS Optimization and Minification Tool

Autoptimize handles CSS aggregation, minification, and cache management for WordPress sites without the broader page caching overhead of full caching plugins. When the MIME type error is traced to a CSS file generated by a minification or combination process, Autoptimize’s settings panel makes it simple to disable individual optimization features — inline CSS, defer CSS loading, exclude specific files — to identify exactly which optimization step causes the server to return HTML instead of CSS. Disabling CSS optimization entirely and re-enabling features one at a time isolates the problematic setting in minutes. Autoptimize is completely free.

FREE — no paid tier
CSS aggregation and minification with correct MIME type output
Individual feature toggles for precise conflict isolation
Exclude specific CSS files from optimization
Works alongside most caching plugins as a complementary tool

Autoptimize’s CSS combination feature combines multiple stylesheets into a single file at a cache directory URL. If a security plugin or CDN restricts access to that cache directory, the combined CSS file returns a 403 error page in HTML — exactly the MIME type mismatch the browser reports. Adding the Autoptimize cache directory URL pattern to the security plugin’s exclusion list resolves this category of conflict.

Screaming Frog SEO Spider — Best Crawler for Site-Wide CSS Error Detection

Screaming Frog SEO Spider crawls an entire website and audits every resource request including stylesheets, reporting their HTTP response codes and content types in a filterable spreadsheet view. For sites with multiple CSS MIME type errors spread across different templates or page types — a problem common after theme migrations or plugin updates that modify how stylesheets are enqueued — Screaming Frog identifies every affected URL in a single crawl rather than requiring manual page-by-page testing. The free version crawls up to 500 URLs, which covers the majority of small websites. The paid license costs £259 per year (approximately $325 USD) and removes all URL limits for enterprise-scale crawls.

Free: crawl up to 500 URLs
Paid license: £259/year (~$325 USD) with unlimited crawling
Reports HTTP response codes and content types per resource
Filterable export for identifying all CSS-related errors
Available for Windows, macOS, and Ubuntu

Screaming Frog is a desktop application that runs locally and requires a reasonably powerful machine for large crawls — websites with 50,000+ URLs require 2GB+ of RAM dedicated to the crawl process. It cannot test authenticated sessions without custom request header configuration, limiting its usefulness for diagnosing MIME type errors behind login walls without additional setup.

WebPageTest — Best Free Deep Network Waterfall Analysis

WebPageTest (webpagetest.org) is a free, open-source web performance testing tool that provides the most detailed HTTP waterfall analysis available at no cost. Its “Request Details” view shows the exact content type returned for every resource, the response headers, the time to first byte, and the connection type — all the information needed to confirm whether a MIME type error is caused by a server configuration issue, a CDN edge caching problem, or a 404 at the origin. The ability to test from dozens of global locations and replay the test at different network speeds makes it the strongest free tool for isolating intermittent MIME type errors that only affect specific geographic regions or connection types. WebPageTest is completely free to use, with no usage limits for standard tests.

FREE — no account required for basic tests
Full HTTP waterfall with content type per resource
Tests from 30+ global locations
Response header inspection for every resource
Open-source with self-hosted enterprise option

WebPageTest tests are run from anonymous sessions and cannot test authenticated content without using script-based login sequences, which requires more technical configuration. Test results are publicly accessible by URL by default, which requires consideration for sites where page content is sensitive — a private instance or a paid testing service offers better confidentiality controls for internal or pre-launch pages.

Pricing Comparison: Free vs Paid Diagnostic Tools

The free tier covers the vast majority of diagnostic scenarios for this error. Query Monitor, Health Check & Troubleshooting, Autoptimize, LiteSpeed Cache, W3 Total Cache, and WebPageTest deliver complete functionality at zero cost. The 500-URL free tier of Screaming Frog covers all small and medium websites. Better Search Replace’s free version handles all single-site domain migrations. GTmetrix’s free tier provides one-location testing that resolves most CDN caching investigations.

Paid tools justify investment when the problem scales beyond a single site. WP Rocket at $59.95 per year pays for itself through time saved on a single production CSS emergency on a high-traffic site. Screaming Frog at £259 per year is justified at agencies managing 10+ client sites where a full site-wide CSS audit once per quarter catches errors before clients report them. GTmetrix’s Advanced plan at $24.99 per month adds multi-location monitoring that detects CDN-specific MIME type errors that single-location testing cannot catch.

How to Choose the Right Diagnostic Approach

The decision between tools depends on what the Network tab reveals when the CSS URL is pasted directly into a browser. A 404 error means the problem is a path issue — start with Query Monitor to see exactly where the path was registered, then flush permalinks. A login page means an authentication barrier is blocking the stylesheet — check security plugins with Health Check’s Troubleshooting Mode. A full HTML error page from a CDN means the CDN cached a previous error — flush the CDN cache immediately and use GTmetrix to test the result from multiple edge locations.

The error appearing on only some pages but not others indicates the problem is template-specific: one page template uses a different stylesheet enqueue path than another. Screaming Frog identifies which pages are affected across the full site in a single crawl. The error appearing only in certain countries or for certain users indicates CDN edge caching divergence — GTmetrix with multiple test locations confirms this and WebPageTest’s global test nodes triangulate which regions are affected.

Frequently Asked Questions

What does “Refused to apply style because its MIME type (‘text/html’) is not a supported stylesheet MIME type” mean?

This browser error means your web server returned an HTML document when the browser requested a CSS stylesheet. Browsers with strict MIME type checking active will not use an HTML file as a stylesheet, so they reject it entirely, leaving the page unstyled. The root cause is almost always a 404 error page, a server error, or a failed WordPress CSS generation process being served in place of the actual CSS file.

How do I find which CSS file is causing the MIME type error?

Open browser developer tools (F12), go to the Console tab to see the full error message including the stylesheet URL, then switch to the Network tab and filter by CSS. The file returning the wrong MIME type shows a red status code or is flagged in the waterfall. Click it to see the Response Headers and confirm the Content-Type is text/html instead of text/css, then paste the CSS URL directly into a new browser tab to see exactly what the server is returning.

Will flushing WordPress permalinks fix this error?

Flushing permalinks resolves the error when the cause is a corrupted WordPress rewrite rule — the case where WordPress routes CSS requests through the main PHP index and returns an HTML response. Go to Settings → Permalinks and click Save Changes to regenerate the .htaccess rewrite rules. This is the fastest fix to try first for any WordPress site showing this error, because it costs 10 seconds and resolves the majority of WordPress-specific cases.

Can a caching plugin cause this MIME type error?

Yes. Caching plugins that store a 404 or error response for a CSS file URL continue serving that cached error response to all visitors even after the underlying CSS file is restored. The browser receives the cached HTML error page with text/html content type and triggers the MIME type error. Clearing all plugin caches, CDN caches, and browser caches simultaneously is required to let the correct CSS file propagate through every layer of the caching stack.

What is the AddType directive and when should I add it to .htaccess?

AddType is an Apache directive that explicitly declares the MIME type the server should report for files with a specific extension. Adding AddType text/css .css to your .htaccess file forces Apache to declare all .css files as text/css regardless of server-level configuration. This is needed when the server’s default MIME type configuration is missing or incorrect for CSS files — most commonly encountered on older or misconfigured shared hosting environments where the server serves CSS files without a Content-Type header or with an incorrect one.

Does this error affect SEO?

Yes. Googlebot and other search engine crawlers fetch stylesheets as part of rendering pages for indexing. When the stylesheet request returns an HTML error page instead of CSS, the crawler renders the page without any visual styling — the same experience a human visitor would see. Unstyled pages reduce the crawler’s ability to understand page structure through visual layout cues, and persistent CSS errors trigger Google Search Console coverage warnings. Fixing the MIME type error promptly protects both user experience and search visibility.

Why does the error only appear for logged-out visitors but not for me when logged in?

WordPress caching plugins and CDNs typically bypass caching for logged-in administrators and serve fresh content directly. When the error cached in the caching layer was triggered by a logged-out user’s request, the cached HTML error response is served to all subsequent logged-out visitors while logged-in administrators receive fresh, correctly-typed CSS files. Clearing all caches removes the stale cached error response and confirms whether the underlying issue has been resolved or only obscured by the cache bypass behavior.

Pro Tips for Resolving and Preventing CSS MIME Type Errors

Add a network monitoring step to the staging deployment checklist before every WordPress update cycle. Running a GTmetrix or WebPageTest report after each plugin or theme update on a staging site takes three minutes and catches stylesheet loading failures before they reach production. Most CSS MIME type errors caused by plugin conflicts surface immediately after an update — catching them on staging eliminates the risk of visitors experiencing an unstyled site while the fix is being applied.

Always test in a fresh browser session with browser cache disabled when diagnosing MIME type errors. Chrome’s DevTools “Disable cache” checkbox in the Network tab, activated while DevTools is open, ensures every resource request bypasses the browser cache during testing. Diagnosing with a warm browser cache produces false results: a previously cached correct CSS file masks an active MIME type error that every other visitor is experiencing on first load.

Avoid using Cloudflare’s “Auto Minify” feature for CSS on WordPress sites using page builders or plugins that generate CSS dynamically. Cloudflare’s auto-minification processes the CSS response at the CDN edge, and if the origin server returns an HTML error page for a CSS URL, Cloudflare sometimes caches and minifies the HTML content while preserving the incorrect content type. Disabling Auto Minify for CSS in Cloudflare Speed settings prevents this class of CDN-induced MIME type error without affecting server-side optimization.

When migrating WordPress sites between domains or hosting environments, run the search-and-replace before changing DNS rather than after. Completing the database URL migration while the old domain is still accessible allows testing of the migrated site through the hosts file before DNS propagation, confirming stylesheets load correctly with the new domain before any visitors encounter the new environment. Post-DNS migration debugging happens under time pressure — pre-migration validation eliminates that pressure entirely.

Keep WP_DEBUG, WP_DEBUG_DISPLAY, and SCRIPT_DEBUG permanently disabled on production sites, even during active development work. When debugging is needed on production, use a plugin like Query Monitor that displays debug output only to logged-in administrators rather than outputting it directly into response streams where it corrupts CSS generation. The pattern of enabling WP_DEBUG on production to diagnose an unrelated issue and then forgetting to disable it is responsible for a significant share of dynamic CSS generation MIME type errors in WordPress.

Set up a simple uptime monitor that checks the response content type for critical stylesheet URLs, not just the HTTP status code. A monitoring service checking only for a 200 OK response reports the page as “up” even when the server is returning an HTML error page with a 200 status code and a text/html content type — exactly the scenario that triggers the MIME type error. Monitoring the actual content type returned by the stylesheet URL provides an earlier, more accurate signal of this class of failure than HTTP status alone.

Resolving the Error for Good

The “Refused to apply style” MIME type error is almost always a symptom of something simpler than its intimidating error message suggests. In 95% of cases, the CSS file is present and correct — the problem is that the request for it is returning a different resource entirely: a 404 error page, a login redirect, a PHP error output, or a CDN-cached stale response. The diagnostic path is consistent regardless of environment: view the CSS URL directly in a browser, identify exactly what the server returns, and fix that upstream problem rather than trying to configure the browser or the stylesheet to tolerate a malformed response.

For WordPress sites specifically, the sequence of flush permalinks → clear all caches → check wp-config.php debug settings → disable plugins one by one resolves the error in the large majority of cases without requiring any server configuration changes. Server-level MIME type configuration — .htaccess AddType directives, Nginx mime.types entries — is the correct fix only after confirming through the Network tab that the CSS file is actually being served with a wrong content type from a correctly-routed URL, not simply returning a 404 that renders as HTML.

The tools covered in this guide — particularly Query Monitor, Health Check & Troubleshooting, and GTmetrix — give every developer the diagnostic capability to identify the exact cause within minutes rather than hours. Install Query Monitor first, flush permalinks, clear all caches, and paste the CSS URL into a browser tab. Those four steps cost under five minutes and solve the error in the vast majority of WordPress cases without any deeper investigation required.

Written by Al Mahbub Khan Full-Stack Developer & Adobe Certified Magento Developer

Refused to apply style because its MIME type (‘text/html’) is not a supported stylesheet MIME type