What is MIME sniffing and why is it dangerous?

MIME sniffing is when a browser ignores the declared Content-Type and guesses the type from the bytes. An attacker can upload a file labelled as an image that actually contains HTML or script, and a sniffing browser may execute it. Sending X-Content-Type-Options: nosniff disables this guessing.

Why is image/svg+xml marked high risk?

SVG is XML and can contain inline script tags and event handlers. When served inline with an image type, a hostile SVG can run JavaScript in your origin, making it a stored XSS vector. Sanitise SVG uploads or serve them as downloads.

When should I use application/octet-stream?

Use it for arbitrary binary downloads you do not want the browser to render, paired with Content-Disposition: attachment and nosniff. Be aware that without nosniff some browsers will still sniff octet-stream into HTML.

Does the correct Content-Type matter if I also set nosniff?

Yes. Even with nosniff, some types require the exact Content-Type to work, such as application/wasm for streaming compilation and ES modules. Setting the right type and nosniff together is the safe combination.

Is my input sent to a server?

No. The lookup runs against a registry bundled into the page and executes entirely in your browser. Nothing you type is transmitted.

What is the MIME Type Inspector & Security Risk Checker?

Look up any MIME type or file extension against a bundled registry and see the correct Content-Type header, whether browsers will sniff it, the security risk, the recommended X-Content-Type-Options value, and the matching CSP directive. Fully offline, nothing transmitted. It runs free in your browser on Gera Tools, with nothing uploaded.

MIME Type Inspector & Security Risk Checker

Name: MIME Type Inspector & Security Risk Checker
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

The Content-Type header tells the browser how to treat a response, and getting it wrong is a recurring source of security bugs. A file served with the wrong type can be sniffed into something executable, and the right type is sometimes required for a feature to work at all. This tool maps any MIME type or file extension to its security profile so you can serve it safely.

How it works

The tool matches your input against a bundled registry, first as an exact MIME type, then as a file extension, then as a partial type name. For the matched entry it reports:

Canonical Content-Type — the value to put in the header.
Sniffability — whether browsers may MIME-sniff this type when nosniff is absent.
Risk level — high for executable or scriptable types (HTML, JavaScript, SVG), lower for inert data and raster images.
Recommended header — X-Content-Type-Options: nosniff, which disables content sniffing across the board.
CSP directive — which Content-Security-Policy directive governs loading this type, for example script-src for JavaScript and img-src for images.

Risk levels explained

Not all MIME types carry the same security risk. The tool classifies them into three tiers:

High risk — types that can contain or execute code:

text/html — directly rendered as a document; can contain inline scripts and event handlers
image/svg+xml — SVG is XML and supports <script> tags and onload attributes; serving untrusted SVG inline is a stored XSS vector
text/javascript / application/javascript — executable script; always restrict with script-src in your CSP
application/xhtml+xml — similar to HTML; parsed by the XML parser but can contain script

Medium risk — types that can embed or reference external resources:

text/css — CSS can use url() imports and was historically exploitable for data exfiltration in older browsers
text/xml / application/xml — XML parsers may resolve external entities (XXE) if not hardened

Low risk — inert binary or text data:

image/png, image/jpeg, image/webp — raster images parsed only by the image decoder
application/pdf — sandboxed by the PDF viewer
application/octet-stream — generic binary; browsers treat it as a download

MIME sniffing: when browsers ignore your header

MIME sniffing occurs when a browser examines the first bytes of a response to determine the actual type, ignoring the declared Content-Type. Internet Explorer popularised this behaviour; Chrome and Firefox maintain it in some cases for compatibility.

The classic attack: an attacker uploads a file with a .jpg extension but it begins with <html>. A sniffing browser that loads it inline may render it as HTML and execute any embedded script. Serving X-Content-Type-Options: nosniff in the response header tells the browser to trust your declared type and never guess.

The tool flags sniffable types so you know where this header is particularly important.

Practical examples

Serving user-uploaded SVG:

Content-Type: image/svg+xml
X-Content-Type-Options: nosniff
Content-Security-Policy: default-src 'none'
Content-Disposition: attachment; filename="upload.svg"

Serving as an attachment prevents inline rendering entirely; the strongest option for untrusted SVG.

Serving an API JSON response:

Content-Type: application/json
X-Content-Type-Options: nosniff

JSON cannot execute as HTML, so the main concern is that clients parse it correctly rather than treating it as plain text.

Serving a Web Worker or ES module:

Content-Type: text/javascript
X-Content-Type-Options: nosniff

Modules strictly require text/javascript; a wrong type (such as text/plain) causes a fetch failure even with a <script type="module"> tag.

A safe default for almost every response is to set the correct Content-Type and always add X-Content-Type-Options: nosniff. Reserve inline rendering for types you fully control, and serve untrusted uploads as attachments.