X-Content-Type-Options
Send `X-Content-Type-Options: nosniff` on every response to stop browsers ignoring your declared Content-Type and guessing at the content instead.
Send this header. There is no meaningful downside for a typical site.
What it does
Browsers historically inspected response bodies and overrode the declared `Content-Type` when it looked wrong — a convenience that let badly configured servers work, at a time when a great many servers were badly configured. The security consequence is direct: a file uploaded by a user and served as `text/plain` could be sniffed as HTML and rendered, executing any script inside it on your origin, with your cookies. The upload did not need to be an HTML file; it needed only to begin with something that looked enough like markup for the heuristic to take the bait.
`nosniff` turns that off. The browser takes the declared type at face value. A response labelled `text/plain` is never treated as HTML, regardless of what the bytes look like. That alone closes the upload case, and it is the reason this header appears in essentially every security baseline.
It does a second, less advertised thing that matters just as much. With `nosniff` set, the browser also enforces the type on `<script>` and `<link rel=stylesheet>` requests: a script served as `text/plain` or `application/octet-stream` is refused rather than executed, and a stylesheet that is not `text/css` is not applied. This blocks a family of attacks where an attacker points a `<script>` tag at an endpoint that returns JSON, a CSV export or an error page, and relies on the browser executing whatever it finds there.
It is the least controversial header on this list — one value, no configuration, no compatibility story to manage, and essentially no legitimate reason to omit it. The only way it causes trouble is by exposing a server that was already sending wrong MIME types and getting away with it, which is a problem it has surfaced rather than created.
What to send
X-Content-Type-Options: nosniff`nosniff` is the only defined value, so there is nothing to tune. Send it on every response rather than only on HTML — the uploads and static assets are exactly where sniffing is dangerous.
Directives and values
The only valid value. Disables MIME sniffing, and additionally makes the browser refuse `<script>` and `<link rel=stylesheet>` responses whose Content-Type is not a JavaScript or CSS type respectively.
Common mistakes
- Sending it only on HTML pages. The risk lives in user-uploaded files and static assets, which are frequently served by a different path — a CDN, an object store, or a separate location block that never sees the header. Apply it globally.
- Serving JavaScript with the wrong Content-Type. With `nosniff` the browser refuses a script served as `text/plain` or `application/octet-stream` rather than executing it anyway. This is the header working as intended, and the fix is the MIME type, not removing the header.
- Treating it as a substitute for upload handling. It prevents a mislabelled upload being interpreted as HTML. It does not validate uploads, and serving user content from your main origin remains a bad idea regardless — a separate domain removes the whole class of problem.
Browser support
Supported in every current browser and has been for many years. There is no legacy behaviour to worry about and no user-visible cost.
Frequently asked questions
What does X-Content-Type-Options: nosniff do?
It stops the browser inspecting a response body and overriding the declared Content-Type. With it set, a response labelled `text/plain` is never rendered as HTML, and scripts or stylesheets with a mismatched Content-Type are refused rather than guessed at.
Are there other values besides nosniff?
No. `nosniff` is the only defined value. Any other value is ignored, so there is nothing to configure beyond deciding to send it.
Can nosniff break my site?
Only where the server is already sending incorrect MIME types — most often JavaScript served as `text/plain` or `application/octet-stream`, which the browser will now refuse to execute. Fix the Content-Type rather than removing the header.
Should nosniff be on API responses too?
Yes. JSON responses are a common target for sniffing-based attacks, and sending the header on every response is simpler to reason about than deciding per route which ones need it.
The free Security Headers Checker reads X-Content-Type-Options from a live response and grades it alongside every other header on this reference — no account needed.
For the longer treatment, read HTTP Security Headers: HSTS, CSP, X-Frame-Options & More in the Learning Center.
Related headers
The most powerful and most misconfigured security header. Most deployed policies provide no XSS protection at all.
Declares who may load your resources at all. Blocks side-channel reads that CORS does not cover.
Forces HTTPS for a fixed period. The one header where a careless value can take a domain offline for months.