MIME Type and Magic Byte Checker

Compare a file's extension, its declared MIME type and its actual signature bytes to see whether they agree, with a hex preview and a polyglot warning.

Runs locally

Everything happens in your browser. What you paste or drop here is never uploaded, logged or stored.

Drop a file here, or click to choose one

Up to 50 MB. Only the first 64 KB is read, in your browser. Never uploaded, never executed, never rendered.

Three claims about one file, and only one of them is evidence

Every uploaded file carries three separate assertions about what it is, and they can all disagree:

The extension - chosen by whoever named the file. Means nothing.
The declared MIME type - sent by the client in the upload request. Also means nothing; it is trivially forged.
The signature bytes - the file's own content. This is the only one that is evidence.

This tool reads all three and reports where they diverge. The interesting cases are an executable named .jpg, a ZIP named .docx that is actually a JAR, and an image whose bytes contain a PHP tag.

The file is never executed or rendered

This page exists to inspect files somebody does not trust, so how it handles them matters. The file is read as bytes in your browser and only the first 64 KB is examined. It is not uploaded. It is not put into an <img>, an <iframe> or a script tag, and no blob: or data: URL is constructed from it. Nothing about it is interpreted - it is only ever compared against a table of byte patterns.

What signatures can and cannot tell you

ZIP containers are the honest limit

DOCX, XLSX, PPTX, ODT, JAR, APK, EPUB and a plain .zip all begin with the same two bytes, because they are all ZIP archives. A signature check identifies the container and says nothing about what is inside it - a Java archive and a Word document are indistinguishable at this level.

The tool reports that rather than guessing. Distinguishing them properly means safely reading the internal [Content_Types].xml, which is a different operation with its own risks - zip bombs among them.

Text formats have no signature at all

JSON, CSV, HTML, SVG and source code have no magic bytes. There is nothing for a signature test to compare against, and the tool says so instead of inventing an answer. Validating a text upload means parsing it as the format you expect - which is the right approach and a different job.

SVG deserves a specific warning: it is an image format that is also XML, and XML can carry script. An SVG rendered inline executes JavaScript in your origin. It passes every "is this an image" check and is still dangerous.

Polyglots and embedded content

A polyglot is a file that is validly two formats at once. The classic is a GIF whose comment block contains PHP: it passes an image check, and then executes if it is ever served by a PHP handler.

Detecting polyglots properly is a research problem. What this tool does is bounded and honest: it looks for script markers - <?php, <script, SVG markup - inside a format that should not contain them, and reports a second recognisable format signature appearing further into the file. Embedded signatures are often completely innocent, thumbnails inside images being the obvious case, so those are reported as context rather than as a finding.

What to do with an upload, in order

Check the bytes, not the extension or the Content-Type.
Rename it yourself - generate a UUID. Never use the client's filename as a path.
Re-encode images and discard the original. This destroys embedded payloads, polyglots and hostile metadata in one step, and strips GPS coordinates as a bonus.
Store it outside the web root, on a path with no execute permission.
Serve from a separate origin with Content-Disposition: attachment and X-Content-Type-Options: nosniff.

File Upload Security Policy Builder generates the server-side code for all of that.

Frequently asked questions

Is my file uploaded?

No. It is read in your browser, and only the first 64 KB. There is no server endpoint behind this page, and the file is never rendered or executed.

Why does my DOCX show as a ZIP?

Because it is one. All Office Open XML formats are ZIP archives and share the same first two bytes. The signature identifies the container honestly rather than guessing which ZIP-based format it is.

My text file was not recognised. Is that a problem?

No. Text formats have no magic bytes, so there is nothing to match. That is a limit of signature checking, not a property of your file - validate text uploads by parsing them as the format you expect.

Does this detect malware?

No, and it will not claim to. It compares a file against a table of format signatures and looks for script markers where they do not belong. That is not malware analysis, and a tool that implied otherwise would be misleading you.

Can a file pass this check and still be dangerous?

Yes. A perfectly valid image can carry a payload that only matters in a specific rendering context, and a valid PDF can contain hostile JavaScript. Signature checking is one layer - re-encoding and safe serving are the ones that actually contain the risk.

References

Related tools

What this tool can and cannot tell you. It reports what is present in the input you provide. It cannot see anything you did not give it, and a clean result means nothing was found in that input - not that the wider system is secure.

Security guidance here follows current published sources - OWASP, MDN, the relevant RFCs, NIST, CISA, FIRST and MITRE - which are linked beside the specific claims they support.