DNS Tools
CONTENT-TYPE HANDLING

MIME Sniffing Checker

Test for the X-Content-Type-Options nosniff header and the Content-Type it relies on, so browsers treat files as the type you declare them to be.

Run MIME sniffing protection

The domain (or a subdomain). The check stays within that name and its www counterpart, like the full assessment.

No sign-up required. Public hosts and addresses only; results show what was observed, nothing is simulated.

What MIME sniffing is

Every HTTP response declares a Content-Type, such as text/html or application/javascript. MIME sniffing is the browser behaviour of inspecting the bytes and sometimes deciding the content is something else. It exists for compatibility with badly configured servers, but it can be abused: a file that was uploaded as an image or plain text, but that contains script, might be interpreted as HTML or JavaScript and run in the context of your site.

The X-Content-Type-Options: nosniff response header switches this guessing off for scripts and styles. The browser then trusts the declared type, and refuses to run a script that is not served with a JavaScript type, or a stylesheet that is not served as CSS.

How to read the result

The tool shows the header value, the Content-Type of the landing page and the effect.

  • nosniff present: the check passes. The only value browsers honour is exactly nosniff, in any letter case.
  • Header missing: reported as a low-severity improvement.
  • Other value: values such as true, 1 or nosniff, nosniff are not honoured. The tool explains why a value is ignored, including the case where two layers each added the header and the values were combined.
  • No Content-Type: informational. Without a declared type, browsers must guess regardless of nosniff.

Why the header depends on correct Content-Type

nosniff is a contract: the server promises the declared types are right. If you enable it while your server labels JavaScript as text/plain or serves CSS as application/octet-stream, browsers will stop running those files and the site can break. Typical culprits are static file servers with incomplete type tables, assets served from object storage without metadata, and APIs that return JSON with an HTML type. Fix the types first, and the header becomes safe to add.

A worked example

Suppose a site stores profile images uploaded by users. An attacker uploads a file named avatar.png that actually contains HTML with a script. If the server serves it as image/png and sends nosniff, the browser treats it as an image and nothing runs. If the header is missing and the file is opened directly, some browsers may inspect the content and render it as a document. The header does not make uploads safe by itself, but it removes this class of surprise and costs nothing to send.

Common problems

  • Missing everywhere: the header was never configured.
  • Present on pages but not on static assets or uploads, because a different server or bucket serves them.
  • Header duplicated by the application and the proxy.
  • Wrong types after enabling: scripts or styles blocked in the browser console with a MIME-type error.
  • Uploaded files served from the main origin with guessed types, which is the exposure nosniff narrows.

How to enable nosniff safely

Prerequisites: confirm that your pages, scripts, styles, fonts and downloads are all served with accurate Content-Type values. Risk: assets with wrong types stop loading. Rollback: remove the header from the affected layer and fix the type, then re-add it.

  1. List the asset types you serve and test their Content-Type with curl -sI https://example.com/app.js.
  2. Correct any wrong types in the server or storage configuration.
  3. Add X-Content-Type-Options: nosniff at the web server, framework or CDN layer, once, not at several.
  4. Load key pages with the browser console open and look for MIME-type blocks.
  5. Re-run this tool and spot-check an asset path as well.

Limits

Only the landing page is examined; static files, downloads and uploads served by another layer can differ, and the tool cannot find them for you. The tool does not test whether your site accepts dangerous uploads or whether any file can be misinterpreted. nosniff is one defensive layer and does not replace validating uploads and serving user content from a separate origin.

Frequently asked questions

Is nosniff safe to enable?

Yes, provided your files are served with accurate Content-Type values. Test key pages first.

Why does 'nosniff, nosniff' fail?

Browsers honour only the exact value nosniff. A combined value from two layers is not recognised, so remove the duplicate.

Does nosniff stop all content-type attacks?

It prevents the browser from reinterpreting declared types for scripts and styles. Other upload risks need other controls.

Why is a missing Content-Type reported?

Without it browsers guess regardless, which nosniff cannot prevent.

Do APIs need this header?

It is harmless and useful for responses that browsers might render, including JSON returned to browsers.

Where should I add it?

At a single layer that all responses pass through, such as the web server or CDN.

Scope of this tool

  • Only the domain's apex and www host are contacted over HTTPS (and port 80 where stated); redirects to any other host are reported, never followed.
  • Spectra identifies itself honestly and does not imitate a browser, so sites that block automated clients may not show their real headers.
  • A single request path (/) is examined from this scanner's network position; other pages, other nodes of a load-balanced site and other regions may differ.
  • If a header is sent more than once, only the first occurrence is examined.
  • Error and redirect responses are not judged: their headers are not representative of the site.

Written by DNS Tools editorial · Last updated 2026-10-09