MIME Type Lookup
How to use this MIME type lookup
- Type a file extension (like .json) to find its MIME type.
- Or type a MIME type (like image/png) to find matching extensions.
- Leave it empty to browse a list of common types.
What is a MIME type?
A MIME type (Multipurpose Internet Mail Extensions) tells a browser or server what kind of file it's dealing with — used in the Content-Type HTTP header, file uploads, and email attachments to determine how content should be handled.
What happens if the wrong MIME type is sent?
Browsers may refuse to render the file correctly, download it instead of displaying it, or in some cases even ignore it entirely as a security precaution.
Can one extension have multiple MIME types?
Rarely, but it can happen due to historical inconsistencies between systems. When in doubt, use the officially registered IANA MIME type for that format.
The type/subtype structure behind every MIME type
Every MIME type follows a consistent "type/subtype" structure, and understanding it makes unfamiliar MIME types much easier to interpret at a glance. The type is a broad category — common ones include text, image, audio, video, application, and multipart — while the subtype identifies the specific format within that category, like png within image, or json within application. This structure is also why "application" shows up so often as a catch-all type: it's used specifically for binary or structured formats that don't fit cleanly into a more specific media category, which is why formats as different as PDFs (application/pdf), JSON data (application/json), and ZIP archives (application/zip) all share the same broad "application" type despite having almost nothing else in common.
The IANA registry, and why some MIME types start with "x-" or "vnd."
MIME types aren't just informally agreed upon — the Internet Assigned Numbers Authority (IANA) maintains an official registry of standardized types, which is what lets a MIME type mean the same specific thing consistently across every browser, server, and email client worldwide. Before a type gets formally registered, or for types never intended for standardization, two informal prefix conventions historically emerged: "x-" (like the older application/x-www-form-urlencoded) marked an experimental, non-standard type, while "vnd." (like application/vnd.ms-excel) marked a vendor-specific type tied to a particular company's proprietary format. Modern practice increasingly favors registering types formally with IANA from the start rather than relying on these prefixes indefinitely, but both conventions remain common in older and still widely used MIME types you'll encounter today.
MIME sniffing — why browsers sometimes ignore the declared Content-Type
In an ideal world, a server's Content-Type header would always correctly and reliably declare what kind of file is being served, but historically, misconfigured servers frequently sent incorrect or missing MIME types, so browsers developed MIME sniffing — inspecting a file's actual byte content to guess its real type, essentially second-guessing the server's own declared header. This made browsing more resilient to sloppy server configuration, but it also created a real security vulnerability: an attacker could upload a file with a misleading extension or Content-Type, and a browser's sniffing logic might still interpret and execute it as active content like HTML or JavaScript. The X-Content-Type-Options: nosniff HTTP header exists specifically to let a server opt out of this browser guessing behavior entirely, forcing strict adherence to the server's own declared Content-Type as a deliberate security hardening measure.
Why a file extension is not a reliable security boundary
A common but genuinely dangerous assumption in file upload handling is trusting a file's extension as if it reliably indicates the file's actual content or safety — it doesn't, because renaming a file's extension is trivial and requires no special tooling at all. A file named "photo.jpg" could easily contain executable script content rather than actual image data, and any application logic that decides how to process an uploaded file purely by checking its extension, rather than by inspecting its actual binary content (verifying its "magic bytes," the specific byte sequence real files of that format reliably begin with), is trusting user-controllable, easily falsified metadata rather than the file's genuine, verified type. This is exactly why properly secured file upload systems validate actual file content server-side, rather than relying on the client-supplied extension or even the client-supplied Content-Type header alone.
Limitations of this tool
This tool looks up MIME types against a curated database of common, widely used file extensions and formats — it doesn't cover every entry in IANA's full official registry, which includes many highly specialized and rarely encountered types beyond typical everyday use. It also doesn't inspect an actual file's real byte content to verify its type (the "magic bytes" check described above) — it only maps a given extension or MIME type name to its known counterpart based on established convention, which is a lookup, not a security or content verification tool.