Fix CSS MIME Type text/html Errors in Gulp and BrowserSync

You will learn what a CSS MIME type error means, why text/html usually indicates a wrong path or server fallback, and how to verify the response and fix Gulp/BrowserSync serving paths.

A stylesheet request must return CSS content with a CSS MIME type, normally:

Content-Type: text/css

When the browser loads this tag:

<link rel="stylesheet" href="assets/styles/custom-style.css">

it sends an HTTP request for /assets/styles/custom-style.css. The server—not Gulp compilation itself—must find that file and respond with its contents as CSS.

The error says the server responded with:

Content-Type: text/html

That is a strong clue that the response is actually an HTML document rather than the requested CSS file. Commonly, it is:

• a 404 error page returned as HTML;
• index.html returned by a development-server fallback rule;
• an application login page or redirect returned as HTML;
• a file being served from a different folder than the one you expect.

Browsers reject this response because interpreting HTML as CSS can hide server mistakes and lead to unexpected behavior. The CSS file may exist in your source folder, but it must also exist in the folder BrowserSync is configured to serve.

Think of a stylesheet URL as an order at a restaurant.

• The browser orders CSS from /assets/styles/custom-style.css.
• The server should deliver a plate labelled text/css containing CSS.
• Instead, it delivers an HTML page labelled text/html—perhaps the restaurant's menu (index.html) or an error message.

The browser notices that the delivered item does not match the order and refuses to use it. The solution is not to force the browser to accept HTML; it is to find out why the server did not deliver the CSS file.

A stylesheet is linked with a <link> element:

<link rel="stylesheet" href="assets/styles/custom-style.css">

The type="text/css" attribute is optional in modern HTML because CSS is the default stylesheet type:

<link rel="stylesheet" href="assets/styles/custom-style.css">

For the following structure, this relative URL is correct when index.html is served from the project root:

project/
├── index.html
└── assets/
    └── styles/
        └── custom-style.css

<!-- index.html -->
<link rel="stylesheet" href="assets/styles/custom-style.css">

/* assets/styles/custom-style.css */
body {
  background: #f4f7fb;
}

However, the URL is resolved relative to the page URL, not merely according to where files appear in your editor. If the page is at /pages/about.html, then the same relative URL requests /pages/assets/styles/custom-style.css, which may not exist.

An absolute site-root URL avoids that particular issue when the server root contains assets:

<link rel="stylesheet" href="/assets/styles/custom-style.css">

Do not add a leading slash unless BrowserSync's configured server root actually contains the assets directory.

Consider this BrowserSync configuration:

browserSync.init({
  server: {
    baseDir: "dist"
  }
});

And this file layout:

project/
├── index.html
└── assets/
    └── styles/
        └── custom-style.css

When you visit the site, this happens:

1. BrowserSync serves files from dist, not from project.

2. The browser loads the page and sees:

   <link rel="stylesheet" href="assets/styles/custom-style.css">
   

3. The browser requests:

   http://localhost:3000/assets/styles/custom-style.css
   

4. BrowserSync looks for this output file:

   dist/assets/styles/custom-style.css
   

5. If Gulp wrote the file only to assets/styles/custom-style.css outside dist, BrowserSync cannot serve it from the configured root.

6. The server may return an HTML error or fallback page.

7. The response has Content-Type: text/html, so the browser refuses to apply it as a stylesheet.

A matching output structure fixes the issue:

project/
└── dist/
    ├── index.html
    └── assets/
        └── styles/
            └── custom-style.css

MIME type checking appears whenever a browser loads a resource that is expected to have a particular kind of content.

• Compiled Sass or Less: A build task creates dist/css/app.css, but the HTML accidentally points to the source .scss location or an old output path.
• Single-page applications: A server fallback sends index.html for every unknown route. A typo such as /asset/app.css can therefore return index.html with text/html.
• Deployment under a subpath: An app hosted at /dashboard/ uses /assets/app.css, which incorrectly points to the domain root rather than /dashboard/assets/app.css.
• Authenticated applications: A protected asset request redirects to an HTML sign-in page. The browser receives HTML where it expected CSS.
• CDN or reverse proxy configuration: A proxy sends an HTML error page when an upstream asset is missing or unavailable.

In each case, inspecting the actual HTTP response is more reliable than judging the URL by its appearance.

In real projects, developers treat generated files as build output and make the server configuration, HTML paths, and Gulp destination agree.

A typical Gulp 4 setup compiles source styles into a public directory that BrowserSync serves:

const { src, dest, series, watch } = require("gulp");
const browserSync = require("browser-sync").create();

function styles() {
  return src("src/styles/**/*.css")
    .pipe(dest("dist/assets/styles"))
    .pipe(browserSync.stream());
}

function serve() {
  browserSync.init({
    server: {
      baseDir: "dist"
    }
  });

  watch("src/styles/**/*.css", styles);
  watch("dist/*.html").on("change", browserSync.reload);
}

exports.default = series(styles, serve);

The corresponding output HTML uses a URL relative to dist/index.html:

<link rel="stylesheet" href="assets/styles/custom-style.css">

Useful debugging pattern:

1. Open browser developer tools.
2. Open the Network panel and reload the page.
3. Select the failed CSS request.
4. Check Status Code, Response Headers, and Response.
5. If the response body starts with <!doctype html>, identify whether it is a 404 page, index.html, a redirect destination, or another server-generated page.

This confirms the real problem before changing build settings blindly.

Assuming the file exists because it exists in the source directory

A development server may serve dist, build, or public, while the file exists only in src.

src/styles/custom-style.css       # Exists here
public/styles/custom-style.css    # But the server needs it here

Avoid it: check the exact output folder configured as BrowserSync's baseDir and ensure the build task copies or generates the stylesheet there.

Using a relative path from a nested page

This can fail when the current HTML page is in a subdirectory:

<!-- Served as /pages/contact.html -->
<link rel="stylesheet" href="assets/styles/custom-style.css">

The browser requests /pages/assets/styles/custom-style.css.

Avoid it: use a correct path for the page location, such as:

<link rel="stylesheet" href="../assets/styles/custom-style.css">

Or, when appropriate for the server root:

<link rel="stylesheet" href="/assets/styles/custom-style.css">

Believing type="text/css" fixes a server response

This does not change the HTTP response header:

<link rel="stylesheet" type="text/css" href="assets/styles/custom-style.css">

Avoid it: fix the file URL, output location, server routing, or server MIME configuration. The optional type attribute cannot turn HTML into CSS.

Ignoring the response body

The console error names a MIME mismatch, but it does not tell you which HTML page was returned.

Avoid it: open the CSS URL directly in the browser or inspect it in Network tools. If you see your application's index.html, a fallback rule is masking a missing asset path.

Configuring an overly broad SPA fallback

A fallback that returns index.html for every request can hide missing static files.

Avoid it: serve static assets before applying application-route fallback logic, and ensure missing asset URLs return a proper 404 response.

A MIME error is different from a CSS styling problem. If the stylesheet response is HTML, the browser does not load the stylesheet at all.

• A CSS response should normally include: Content-Type: text/css
• text/html for a CSS request means the server sent HTML instead of the stylesheet.
• Inspect the failed request in DevTools → Network.
• Read the response body: it is often a 404 page or index.html fallback.
• BrowserSync serves files from server.baseDir.
• Gulp must write/copy compiled CSS inside that served directory.
• Relative URLs are resolved from the current page URL.
• type="text/css" is optional and does not fix a server-side MIME mismatch.
• Verify the final output path, not only the source path.

<link rel="stylesheet" href="assets/styles/custom-style.css">

browserSync.init({
  server: { baseDir: "dist" }
});

If baseDir is dist, the stylesheet should be available at:

dist/assets/styles/custom-style.css

Why does my CSS file have a MIME type of text/html?

The CSS file itself usually does not. The server returned an HTML page—often a 404 page, an index.html fallback, or a login page—for the stylesheet URL.

How can I see the HTML that was returned instead of CSS?

Open the stylesheet request in the browser Network panel and inspect the Response tab. You can also paste the stylesheet URL into the address bar.

Is type="text/css" required on a <link> tag?

No. Modern HTML assumes CSS for rel="stylesheet". Adding the attribute does not fix an incorrect server response.

Can Gulp cause a CSS MIME type error?

Indirectly. Gulp may compile the CSS to a folder that BrowserSync does not serve, or it may not copy the output file where the HTML expects it.

Can BrowserSync cause this error?

Yes, if its baseDir does not match the folder containing the generated assets, or if a proxy/fallback configuration responds with HTML for a missing CSS URL.

Why does the path work in my editor but fail in the browser?

Your editor shows the project filesystem. The browser can access only URLs exposed by the development server, using the server's configured root and routing rules.

Should I use /assets/... or assets/...?

Use /assets/... only when assets is located at the server root. Use assets/... when the HTML page is at that same root. For nested pages, adjust the relative path or use a consistent site-root setup.

• HTTP Content-Type headers — The server uses these headers to describe the type of data in a response.
• Static file serving — Development servers map request URLs to files in a public directory.
• Relative and absolute URLs — URL resolution determines which path the browser actually requests.
• Gulp build pipelines — Source files are transformed and written to an output directory.
• BrowserSync configuration — baseDir and proxy settings control what BrowserSync serves.
• Browser developer tools Network panel — It reveals request URLs, status codes, headers, redirects, and response bodies.
• Single-page application fallbacks — Route fallbacks can accidentally return index.html for missing assets.
• HTTP status codes — A 404, 301, 302, or 200 response can each help identify why an asset request failed.