Skip to main content
Security Tools

X-Content-Type-Options Checker

Check whether a website sends an X-Content-Type-Options header to prevent MIME-sniffing.

Enter a domain to check whether it sends an X-Content-Type-Options header.

JustChecker monitors your security headers continuously and alerts you if any regress.

What Is X-Content-Type-Options?

Setting X-Content-Type-Options: nosniff stops browsers from guessing ("sniffing") a file's type and treating, for example, an uploaded text file as a script. This tool checks whether the header is sent.

When to Use It

  • On any site, and especially those that serve user uploads.
  • During security reviews.

How to Use It

  1. Enter the domain.
  2. Check that the value is exactly nosniff.

Understanding the Result

nosniff is the only valid value. It is safe to add site-wide as long as your server sends correct Content-Type headers.

Limitations

The check covers the page you enter; ideally the header is set for all responses, including files and API endpoints.

What MIME Sniffing Attacks Look Like

Suppose users can upload profile pictures, and someone uploads a file named avatar.jpg that actually contains JavaScript. Without nosniff, an older browser might inspect the content, decide it looks like a script, and run it when the file is referenced by a <script> tag. With nosniff, the browser trusts the declared Content-Type: image/jpeg and refuses.

How to Add It

# Nginx
add_header X-Content-Type-Options "nosniff" always;

# Apache
Header always set X-Content-Type-Options "nosniff"

# Express (Node.js) - the helmet package sets it by default
app.use(helmet());

Before You Enable It

  • Make sure your server sends correct Content-Type headers, especially text/css for stylesheets and text/javascript for scripts - with nosniff, a stylesheet served as text/plain is blocked.
  • Include it on API responses and user-uploaded files, not just HTML pages.

Check every security header together with the Security Headers Checker and our security headers checklist.

Frequently Asked Questions

Some browsers historically tried to guess a file's actual type by inspecting its content rather than trusting the declared Content-Type header - an attacker could exploit this by disguising executable script content as an "innocent" file type that gets sniffed and executed anyway.

It instructs the browser to strictly trust the declared Content-Type header and never attempt to guess a different type, closing off the MIME-sniffing attack vector entirely.

It's still relevant defense-in-depth for any static assets you serve, but it becomes especially important for sites that serve user-uploaded content, where an attacker has more control over what gets uploaded and potentially mis-typed.

It has exactly one valid value ("nosniff") and no configuration complexity - it's effectively an on/off switch, making it one of the easiest security headers to add with essentially no risk of breaking legitimate functionality.

Modern browsers have significantly reduced sniffing behavior compared to older versions, but explicitly setting this header remains a cheap, zero-downside best practice rather than relying on browser defaults alone.

No - it's one specific mitigation against one specific technique; proper upload validation, storage isolation, and content-type enforcement in your application remain necessary regardless.
Share this tool: