Download the PHP package softcreatr/php-mime-detector without Composer

PHP Mime Detector

A modern, extensible MIME type detector for PHP that analyses the initial bytes of a file instead of trusting its extension. The detector ships with a modular pipeline of signature matchers and a bidirectional repository of MIME type ↔ extension mappings. Signature detection is a best-effort format hint; validate file structure and apply upload policy separately when handling untrusted files.

Features

• Real file inspection – identifies file formats by signature instead of relying on filenames. See the supported file types for detection results, MIME aliases and variant coverage, also available in the Wiki.
• Composable architecture – category-specific detectors can be swapped in or extended without touching the core.
• Rich lookup helpers – translate between MIME types and extensions in both directions and enumerate the supported catalogue.
• No runtime packages – requires PHP 8.1+ and ext-ctype. It uses ZipArchive for deeper ZIP inspection when that extension is available.

Installation

Install the package via Composer:

Quick start

Detecting the MIME type and the preferred extension for a file is as simple as instantiating the façade and calling its helpers:

Resolving MIME types and extensions

The façade exposes several lookup helpers that do not require a file scan. They operate on the shared repository of known mappings:

Comparing MIME names

Some tools use different names for the same format. Most existing MIME return values are preserved, but newly distinguished formats have new results; see the upgrade notes. Use MimeTypeAliases to compare a detector result with another source, such as PHP's fileinfo, or to request a preferred name:

The alias list is audited across the complete bundled catalogue against libmagic, shared-mime-info, WebKit, and IANA definitions. See the MIME compatibility audit for sources, accepted aliases, and excluded comparisons. In particular, audio/ogg and audio/opus, or font/sfnt and font/ttf, describe different levels of a format and are not treated as interchangeable. Unknown names only match when their normalized names are identical. The preferred name is not guaranteed to be IANA registered for every format.

For Ogg Opus files, getMimeType() still returns the legacy audio/opus value, while getPreferredMimeType() returns the audio/ogg container type recommended by RFC 7845. The generic alias helper does not equate codec and container names.

Need a data URI? The detector will encode the configured file for you:

Optional ZipArchive support

The detector is fully functional without PHP's ZipArchive extension; ZIP signatures are recognised by scanning the first 4 KiB of the file for well-known markers such as mimetype, [Content_Types].xml, or classes.dex. When the extension is present, the ZipSignatureDetector opens the archive and inspects its entries directly. This deeper look allows the detector to resolve format families like OOXML (.docx, .pptx, .xlsx), APK/JAR/XPI bundles, and iWork (.pages, .numbers, .key) even when their identifying data lives deeper inside the archive than the cached bytes. iWork classification reads a bounded portion of Index/Document.iwa; shared ZIP entry names alone cannot distinguish Pages from Numbers.

If the extension is missing, the detector simply falls back to its heuristic path and ultimately reports a generic application/zip match whenever a more specific signature cannot be derived. Unit tests that require ZipArchive are skipped automatically when the class is not available, so no additional setup is needed to run the suite.

ISO 9660 images are identified from their volume descriptor at sector 16. Apple UDIF disk images use their final 512-byte trailer. PE executables and ID3-tagged audio can require a small read beyond the initial cache. These checks use bounded reads from seekable files; an input that cannot be sought falls back to the other detectors.

Extending the detector

Custom formats can be added without modifying the library itself. Choose the approach that fits your needs best.

Registering detectors via extensions

When you only need to extend the default pipeline, extensions are the quickest way to plug in extra detectors. The snippet below is a complete, copy & paste ready bootstrap that you can drop into a service provider, bootstrap.php, or any other file that runs before you instantiate the façade:

Extensions can be forgotten at runtime (MimeTypeDetector::forgetExtension('custom-container')) or reset entirely (MimeTypeDetector::flushExtensions()). Returning multiple detectors from an extension lets you register related matchers in one go while still benefiting from the priority-based ordering.

Building a custom pipeline

For more advanced scenarios you can compose a bespoke pipeline. Follow these steps to teach the detector about a new signature and MIME mapping.

1. Implement a signature detector

Create a class that implements SoftCreatR\MimeDetector\Contract\FileSignatureDetectorInterface. The detector receives the DetectionContext, which gives access to the file buffer and lets you return a MimeTypeMatch when the signature is recognised.

2. Register MIME mappings

Extend the repository so your MIME type resolves to the expected extension(s):

3. Compose (or customise) the detector pipeline

Most projects do not need to rebuild the pipeline manually. Once an extension is registered it is automatically merged with the default signature detectors in priority order:

If you do need full control you can still provide a bespoke pipeline. Simply prepend your detector to the default ones so it executes before the fallback signatures:

From this point the new MIME type behaves exactly like the built-in ones – it can be detected from files, resolved by MIME type, and listed in the catalogue.

Testing

Fixture files for the test suite are stored in a Git submodule. After cloning this repository run:

The fixture corpus lives in the separate mime-detector-fixtures repository. Run php tools/compare-fileinfo.php to compare the complete local corpus with PHP's fileinfo (requires ext-fileinfo for this development tool). Differences include format/container distinctions and gaps in either detector; they need review before changing an upload policy.

Keeping the submodule means the fixtures are not bundled into Composer installs; Git source archives do not include submodule contents. Add new binary fixtures there and update the submodule reference when publishing a coordinated change.

Contributing

We welcome pull requests! Please review CONTRIBUTING for the coding standards and workflow. When adding new detections, include at least one fixture so behaviour can be verified automatically.

License

Released under the ISC License.