Declare a Content-Type, drop a file or paste its leading bytes, and see what a browser would actually sniff the response to. It catches the upload trap where a file declared as an image is really markup, no nosniff is set, and the browser runs the script inside it.
A server sends a Content-Type header to tell the browser what a response is. The catch is that browsers do not always trust it. When the header looks wrong or generic, a browser may run a content sniffing step that inspects the first bytes of the body and decides the type for itself. That behaviour is standardised in the WHATWG mime sniffing standard, and it is the root of a whole class of upload bugs. This tool runs a simplified version of those rules over the bytes you give it and tells you what the browser would conclude.
Imagine an app that lets users upload an avatar and serves it back with Content-Type: image/png. An attacker uploads a file whose first bytes are not a real PNG but a snippet of markup, something starting with a doctype or a script tag. If the response carries no nosniff header and a victim opens the file directly, a browser that sniffs the body can decide it is text/html, render it as a page, and run the script in the origin that served it. That is stored cross site scripting delivered through an image field, a textbook case of content type confusion.
The checker recognises the patterns a browser keys on:
<html>, <head>, <script>, or a bare leading < followed by a tag name. These can sniff to text/html, which runs script.%PDF) and a ZIP header (PK), which are container types.The header value nosniff on X-Content-Type-Options tells the browser to stop guessing and honour the declared type. With it set, a response declared image/png is treated as an image even when the bytes look like a page, so the markup is not rendered and the script does not run. The verdict below reflects this: the same risky bytes are flagged loudly when nosniff is absent and marked as held back when it is present.
The tool reports the type it sniffed from the bytes, the type you declared, and whether they agree. The loud flag fires in one specific situation: the bytes sniff to an executable type like text/html while you declared something benign such as an image, plain text, or a generic byte stream, and nosniff is not set. That is the combination an attacker needs. The fixes are always the same: send the correct Content-Type, always set X-Content-Type-Options: nosniff, serve user uploads from a separate origin so a sniffed page cannot reach your real one, and force a download with Content-Disposition for files that should never render. Judging whether a real upload pipeline is safe means understanding how the whole flow stores and serves files, which is the kind of context an AI security testing approach reasons about rather than matching one byte string. For the wider set of injection and rendering boundaries attackers probe, see the web application security writing.