text/css CSS Flagship
Identifies CSS stylesheets — required for the browser to apply styles from a linked file.
What it's for
text/css identifies CSS stylesheet files — required for a browser to actually apply styles from a linked <link rel="stylesheet"> resource. Unlike some other content types where browsers are historically lenient about mismatched or missing MIME types, CSS Content-Type checking has gotten stricter over time specifically for security reasons, making this one of the MIME types where getting it wrong causes very visible, immediate breakage rather than a subtle issue.
Format & syntax
Content-Type: text/css
Content-Type: text/css; charset=utf-8
No special structure requirements beyond valid CSS syntax. As with HTML, an explicit charset matters more here than for some other types, since CSS files can contain non-ASCII characters (in content strings, font names, comments) that need correct encoding to avoid rendering issues.
How it's used in practice
- Linked stylesheets — every
<link rel="stylesheet" href="...">reference depends on the server correctly serving that file astext/css; this is by far the most common real-world use. - CSS served from a CDN or object storage — similar to JavaScript, cloud storage buckets sometimes default to
application/octet-streamfor uploaded.cssfiles unless the Content-Type is explicitly set at upload time, causing styles to silently fail to apply. - Dynamically generated stylesheets — CSS-in-JS solutions, theme generators, or any endpoint that constructs CSS on the fly needs to explicitly set this Content-Type, since there's no static file extension to infer it from.
@importand cross-origin stylesheet loading — cross-origin CSS loading has its own MIME-type strictness considerations, particularly in the context of Cross-Origin Resource Sharing and Subresource Integrity checks that some setups apply to stylesheet loading.
Common mistakes & gotchas
- Browsers refusing to apply styles when Content-Type is wrong (strict MIME checking) — modern browsers enforce strict MIME type checking for stylesheets in standards mode: if a linked "CSS" file is actually served with a non-CSS Content-Type (like
text/plainortext/html, common if a server returns an error page for a missing file), the browser will refuse to apply it as a stylesheet at all, rather than trying to guess — this shows up as "styles not loading" with no obvious error beyond a console warning about MIME type mismatch. - A misconfigured server/CDN returning an HTML error page with a 200 status for a missing CSS file — if your CSS file path is wrong and the server responds with a custom 404 HTML page but (incorrectly) a 200 status and
text/htmlcontent type, the browser will see it fails the CSS MIME check and silently skip applying it, which can be a confusing debugging experience since there's no obvious "file not found" signal in the rendered page. - Cloud storage buckets defaulting to the wrong Content-Type on upload — a very common real-world gotcha: uploading
.cssfiles to S3, GCS, or similar object storage without explicitly setting the Content-Type metadata often results inapplication/octet-streamor a generic default, breaking styling when served directly from the bucket. - Charset mismatches causing garbled special characters in CSS content — less common than in HTML, but CSS content strings (used in
content: "..."for pseudo-elements, for example) can still be affected by encoding mismatches.
Comparison & FAQ
| Type | Purpose | Key difference from text/css |
|---|---|---|
| text/html | Page markup | Different asset class entirely, but shares the pattern of needing correct MIME type for the browser to process it as intended |
| text/javascript | Script files | Also has MIME-type checking considerations, though CSS's strict-mode enforcement is particularly unforgiving |
Why aren't my styles being applied even though the CSS file loads fine when I open it directly?
Check the actual Content-Type header being sent for that file — if it's anything other than text/css (commonly text/plain or text/html from a misconfigured server), modern browsers in strict mode will refuse to apply it as a stylesheet, even though the file's content looks correct.
Why would a 404 page break my CSS loading silently?
If your server responds to a missing CSS file with a custom error page that returns a 200 OK status and text/html Content-Type instead of a proper 404, the browser fetches what it thinks is your stylesheet, sees it's actually HTML, and refuses to apply it — with no obvious visual error beyond a console warning.
How do I fix CSS not loading correctly from cloud storage?
Explicitly set the Content-Type metadata to text/css when uploading the file to your storage bucket/CDN — most cloud storage providers won't reliably auto-detect this correctly without it being set explicitly at upload time.
Does browser strict MIME checking apply to all stylesheet loading methods?
It primarily and most strictly applies to <link rel="stylesheet"> loading in standards-mode documents; other mechanisms for including CSS may have somewhat different enforcement behavior, but treating correct Content-Type as mandatory for all CSS delivery is the safest practice regardless.