Magic Bytes vs MIME Type vs File Extension

File type detection usually involves three signals: the extension, the MIME type, and the magic bytes. They answer different questions and have different trust levels.

The right approach is not to choose one signal forever. Use each signal for the job it is good at, and decide which one wins when they disagree.

File extensions are labels

An extension is part of the filename. It is useful because people and operating systems understand it, but it is not proof of content.

Renaming report.exe to report.pdf changes the label only. The bytes at the beginning still start with the Windows executable signature 4D 5A, not the PDF signature 25 50 44 46 2D.

Use extensions for:

• Displaying filenames.
• Picking a default icon.
• Choosing an expected allowlist rule.
• Warning users when the name and content disagree.

Do not use extensions alone for upload security or automated processing.

MIME types are metadata

A MIME type is a text label such as image/png or application/pdf. It can come from an HTTP header, a database column, an operating system registry, a library, or a browser sniffing algorithm.

On upload, the most dangerous MIME value is the one in the multipart request. The client controls it:

curl -F "file=@script.php;type=image/png" https://example.com/upload

That request tells the server the file is image/png, even though the bytes can be PHP source. A browser may also infer a MIME type from extension or limited content sniffing. That can be useful for display, but it is not a validation boundary.

Use MIME types for:

• HTTP Content-Type responses after you have validated or generated the file.
• Database metadata that records your own detection result.
• Matching downstream processors that expect MIME labels.

Do not treat client-supplied MIME values as proof.

Magic bytes are content signals

Magic bytes are byte sequences inside the file. They are often at offset 0, but some formats store their identifying bytes later.

Examples:

Magic-byte matching is a stronger first check because it reads the content. You can try it directly with the lookup tool or query:

curl "https://filesignature.org/api/v1/identify?hex=89%2050%204E%2047%200D%200A%201A%200A"

When the signals disagree

For upload validation, treat disagreement as a warning or rejection.

The magic bytes should usually decide the first parser to use. The extension and MIME type can then be checked for consistency.

Shared signatures require second-level checks

Magic bytes can identify the container but not always the exact format. The ZIP signature is the classic example. DOCX, XLSX, PPTX, APK, JAR, EPUB, and many other formats all use ZIP containers.

For these files, do two checks:

1. Confirm the container signature.
2. Inspect required internal files or fields.

Examples:

• DOCX requires Open Packaging Convention metadata and a word/ directory.
• XLSX requires an xl/ directory.
• EPUB requires a mimetype file with application/epub+zip.
• WEBP requires a RIFF header plus WEBP as the form type at offset 8.

This is why a file identification API can return multiple matches for one header. It is reporting all candidates that match the bytes you supplied.

Recommended validation order

For server-side validation:

1. Normalize the filename and extension.
2. Read enough header bytes for every format in your allowlist.
3. Compare magic bytes at the documented offsets.
4. For containers, inspect the internal structure.
5. Confirm the detected type is allowed for that endpoint.
6. Store your own detected type and MIME label.
7. Serve the file with a safe Content-Type only after validation.

The extension is for humans. The MIME type is for metadata and HTTP. The magic bytes are the content-level starting point for detection.