How to Identify a File Type with Magic Bytes, MIME and Extension

Use three signals: extension, declared MIME, and bytes

A filename such as report.pdf is only a label. A browser or server may also attach a MIME type. Neither is as strong as checking recognizable bytes in the file itself, but even a byte signature is not a complete security scan.

Common signature examples

Many binary formats begin with recognizable markers, although signatures and container formats can overlap. Office files, for example, are normally ZIP-based packages, so the first bytes alone cannot distinguish every DOCX/XLSX/PPTX without inspecting the package structure.

What to do when extension and bytes disagree

Do not simply rename the file until you know why the mismatch exists. A harmless case may be a download with the wrong extension; a risky case may be an executable or script disguised as a document. Preserve the original file, identify the actual type, and use a compatible parser/viewer in a safe environment.

Why browser-local inspection is useful

For ordinary file identification, only a small prefix and sometimes limited container metadata need to be read. A local tool can perform that check without uploading the entire file, which is valuable for private documents. The tool should still disclose any format that requires deeper parsing or an external codec.

Use the result to choose the next tool

Once the type is identified, decide whether you need to open, convert, extract, resize, inspect metadata, or simply rename the extension. Avoid unnecessary conversion; every conversion can change metadata, quality, formulas, layout, or embedded objects.

Container formats are why one signature is sometimes not enough

DOCX, XLSX and PPTX are ZIP-based packages. EPUB and other formats can also use ZIP containers. Seeing the PK ZIP signature establishes the outer container but not the business format; a format-aware checker must inspect internal paths/metadata such as content types and package structure.

Likewise, text formats such as JSON, XML, CSV or source code may have no unique magic bytes. Identification then relies on syntax, encoding and parsing rather than one fixed binary prefix.

Scenario: invoice.pdf.exe

A filename can be crafted so the visible beginning looks like a document while the actual extension or content is executable. Preserve the original full name, inspect the content/signature and do not ‘fix’ the problem by renaming the file to .pdf.

If the content is unknown, that is a valid result. Escalate to the appropriate security/forensic workflow instead of forcing the file into the closest recognizable category.

Use an evidence ladder when the result is uncertain

Start with the original filename/source context, then compare extension, browser-declared MIME and byte signature. If those disagree or the outer format is a container, use a format-aware parser. Preserve the original until the mismatch is explained.

‘Unknown’ is often the most responsible result for encrypted, proprietary, truncated or text-like files with no unique signature. A detector should expose what it knows instead of fabricating certainty from a few printable strings.

Renaming a file is not the same as converting it

If the bytes are a PNG and the filename ends in .jpg, changing the suffix to .png can correct the label after you have verified the content. But if a destination requires JPEG, the file must be decoded and re-encoded into JPEG; merely changing .png to .jpg creates a mislabeled file that may fail later.

The same principle applies to documents and containers. Renaming a ZIP package to .docx does not create a valid Word document unless the internal Office package structure is actually present. Use identification to decide whether the name is wrong or the format needs real conversion.