X-Content-Type-Options: nosniff Explained
By Nathan Cole, Security Researcher · Updated 2026-06-02Part of our guide to HTTP Security Headers Explained: The Complete Guide.
X-Content-Type-Options: nosniff tells the browser to stop guessing what a file is and to trust the Content-Type the server sent. That one instruction closes a whole class of MIME-sniffing attacks, where content delivered under one type gets reinterpreted as another and runs as code. It has a single valid value, it rarely breaks anything, and it is one of the cheapest wins in your header stack. For how it sits alongside the other response headers, start with our pillar on HTTP security headers explained.
MIME sniffing is a behavior browsers adopted years ago to be forgiving. When a server sent an ambiguous or missing Content-Type, the browser would peek at the actual bytes and decide for itself: this looks like HTML, so render it as HTML; this looks like a script, so execute it. Helpful in theory, dangerous in practice. An attacker who can get a file onto your origin (an uploaded "image," a user comment, a generated document) can craft bytes that the browser sniffs as HTML or JavaScript, and suddenly content you treated as inert runs in your users' sessions. The header that disables this is documented by MDN, and it appears on nearly every hardening checklist, including the OWASP Secure Headers project. If you are reviewing the full set, our pillar on HTTP security headers explained ties them together.
The one value
There is exactly one value, and you will never need another:
X-Content-Type-Options: nosniff
When this is present, the browser honors the declared type and refuses to second-guess it. Two specific protections follow. First, a response declared as a non-executable type will not be run as script. Second, browsers apply stricter rules to script and stylesheet loads: a resource pulled in by a script tag must arrive with a JavaScript MIME type, and a stylesheet must arrive as CSS, or the browser blocks it outright instead of sniffing a fallback.
With and without nosniff
| Scenario | Without nosniff | With nosniff |
|---|---|---|
| File served with no Content-Type | Browser guesses from bytes | Browser treats it conservatively, no script execution from a guess |
| Uploaded "image" that contains HTML | May be sniffed and rendered as HTML | Stays the declared type, HTML does not execute |
script src pointing at a non-JS type |
May still execute if bytes look like JS | Blocked unless the type is a JavaScript MIME type |
| Stylesheet with a wrong Content-Type | May still be applied | Rejected; stylesheet is not loaded |
The table makes the trade visible. The protection only works because the browser now relies on your declared types, so the burden shifts to the server: send accurate Content-Type headers.
The one requirement: correct Content-Type headers
Because nosniff makes the browser strict, anything your server mislabels will break instead of silently being rescued by sniffing. Common things to verify:
- JavaScript files are served as
text/javascript(orapplication/javascript), nottext/plainorapplication/octet-stream. - CSS files are served as
text/css. - User-uploaded files get a deliberate, safe
Content-Type, ideallyapplication/octet-streamwith aContent-Disposition: attachmentso they download rather than render. - Generated responses (PDFs, JSON, images) carry the type that matches their bytes.
If your server is already configured sensibly, turning on nosniff changes nothing visible and quietly removes a real attack surface. If it surfaces a mislabeled asset, that asset was a latent bug regardless, and you have just found it.
A safe, easy win
Few security headers are this low-risk. There is no policy to tune, no allowlist to maintain, no per-route logic. You add one header, globally, at the edge or in your application, and you are done:
X-Content-Type-Options: nosniff
Apply it to every response, not only HTML pages. APIs, uploads, and static assets all benefit, and uploads are exactly where MIME confusion tends to bite. After you deploy it, confirm the header is actually present on the wire, since proxies and CDNs sometimes strip headers they do not recognize. Our guide on how to check security headers walks through reading them from a live response, and CSP explained covers the policy header that pairs well with nosniff for defense in depth.
Curious what your site sends today? Scan your domain's headers free at domainintel.app for a quick report of what is set, what is missing, and what to fix next.
Frequently asked questions
What does X-Content-Type-Options: nosniff do?
It stops the browser from guessing a response's type and forces it to trust the Content-Type header the server declared. A file served as text stays text, even if its bytes look like script.
What attack does nosniff prevent?
MIME confusion attacks, where a file uploaded or served as one type is reinterpreted by the browser as a different, executable type such as HTML or JavaScript, leading to cross-site scripting or content injection.
Are there downsides to nosniff?
Very few. The one requirement is that your server sends correct Content-Type headers, because the browser will now honor them strictly. A stylesheet mislabeled as plain text, for example, will be rejected rather than sniffed and accepted.