File signature checker

The extension is a claim; the bytes are the evidence

A filename ending in .jpg tells you what somebody decided to call the file. It tells you nothing about what is in it. The first few bytes usually do — most binary formats begin with a fixed pattern, the magic number, put there precisely so a program can recognise the file without trusting its name.

Drop a file above and the page reads the first 512 bytes and tells you what they say. It never reads more than that, and it never sends anything anywhere — which is the point, because the usual reason to check a file’s type is that you do not trust it.

What a mismatch means, and what it does not

If the extension and the bytes disagree, the page says so. Common innocent causes:

• Someone renamed a .png to .jpg to get past an upload filter.
• A download was saved with the wrong extension because the server sent the wrong Content-Type.
• The file is a .docx, and .docx files are ZIP archives. The bytes are right, the expectation was wrong.

Common less innocent causes: a script or executable wearing an image extension, or a polyglot file crafted to be valid as two formats at once. A mismatch is a reason to look, not a verdict.

A match proves less than it looks like it does. The magic number is the first few bytes and nothing else. A file can start with %PDF- and be almost entirely something else. Signature checking is a fast filter, not a validator.

The cases that catch people out

PK is not “a ZIP file”

50 4B 03 04 — PK followed by two control bytes, after Phil Katz — is the start of every ZIP archive. It is also the start of every .docx, .xlsx, .pptx, .odt, .jar, .apk and .epub, because all of them are ZIP archives with an agreed layout inside. No amount of reading the first bytes will separate them; you have to open the archive and look at what is in it.

RIFF and ftyp need a second look

Some formats put a generic container marker first and the actual format a few bytes later:

ISO base media does the same with ftyp at offset 4 and a brand at 8 — which is why MP4, MOV, HEIC and AVIF all look identical for the first four bytes. Any table with one pattern per format gets these wrong.

CA FE BA BE is two things

It is the magic number of a Java .class file, chosen in 1991 because it is a pronounceable hexadecimal word. It is also the magic number of a Mach-O universal binary on macOS. Both are correct; a tool that picks one is guessing.

tar has its signature 257 bytes in

ustar appears at offset 257, not at the start, because tar predates the convention of putting a header at the front of the file. Read only the first sixteen bytes and every tar file is unidentifiable.

Formats with no signature at all

Plain text, CSV, JSON, HTML, JavaScript, Markdown, most source code — none of them have one, because they were never designed to be recognised by a machine reading four bytes. If the page says “no known signature”, that is often the correct answer rather than a failure.

The exception is a byte order mark: EF BB BF at the start of a text file is a UTF-8 BOM, and it is the reason a CSV occasionally opens with a stray  in the first cell.

Related

Everything happens in your browser. If you want to check a file’s contents rather than its type, the hash generator fingerprints it the same way.