File Type and Magic Byte Detector

Identify what a file really is from its signature bytes rather than its name, with container formats recognised and extension mismatches flagged.

Runs locally

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

Drop files to identify them

Only the first 64 KB of each file is read. Nothing is uploaded.

A filename is a claim, not evidence

The extension on a file is a label someone chose. So is the media type your browser reports, which it derives from that same extension. Neither has looked at the contents.

The contents usually identify themselves. Most binary formats begin with a fixed signature - a PDF starts %PDF-, a PNG with a specific eight bytes, a Windows executable with MZ. Reading those is how you find out what a file actually is, and it is the check that catches an executable named holiday-photo.jpg.

Some formats need looking inside, not just at the front

A DOCX is a ZIP. So is an XLSX, a JAR, an APK and an EPUB. Reporting all of them as "ZIP archive" is true and unhelpful, so when a ZIP signature is found this reads the first entries inside it - word/ means DOCX, META-INF/MANIFEST.MF means JAR, and so on. RIFF containers get the same treatment, since WAV, AVI and WebP share a signature and differ four bytes later.

That distinction has teeth: a JAR and an APK are executable code, and a filter that saw only "ZIP" would wave them through.

What a clean result does not mean

Matching signature and extension means the file is the type it claims to be. It does not mean the file is safe. A genuine PDF can carry an exploit; a genuine DOCX can carry a macro. Type detection answers "what is this", which is a prerequisite for deciding what to do with it, not a verdict on it.

Equally, plain text files - CSV, JSON, source code, logs - have no signature at all, so "unrecognised" for one of those is the expected answer rather than a failure.

For upload validation

If you are building an upload endpoint, content inspection like this belongs on the server and should be an allow-list of types you accept, not a block-list of ones you do not. The File Upload Security Policy Builder covers the whole shape of that, and the MIME and Magic Byte Checker focuses on the declared-versus-actual comparison specifically.

Frequently asked questions

Why does it only read part of the file?

Because that is all an identification needs. Signatures live in the first few bytes - the furthest this looks is offset 257, for TAR - so reading 64 KB instead of a 4 GB disk image is the difference between instant and a killed tab.

It says my .txt file is unrecognised.

Expected. Text formats have no magic bytes. The result distinguishes "no signature but reads as text" from "no signature and binary", and the second is the one worth looking at.

Can a file be made to fake a signature?

Yes. Signatures are just bytes, and some formats tolerate junk before their real content. This detects mislabelling, which is common and often accidental; it is not a defence against someone deliberately crafting a polyglot file.

Are my files uploaded?

No. Only the first 64 KB of each is read, locally, and nothing is transmitted.

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.