A file extension maps to a MIME type so servers, browsers, and email clients know how to handle the bytes that follow. The string image/png tells a browser to render pixels, application/json tells a parser to build a tree, and font/woff2 tells the engine to treat the body as a Web Open Font Format container. The MIME Type Lookup tool gives you 24 of these mappings, cross-checked against the IANA media types registry and MDN's common-types table, so you can find a registered base type by extension, format family, or partial string and copy it directly into a Content-Type header, allowlist, or test fixture. Because the copy action places only the base type on your clipboard, you can paste the result into a server route, a JSON config, or a curl command without dragging along parameters that may not belong. Each entry keeps the extension aliases, the registered media type, and a plain-English format label together so you can confirm what you are about to send before you send it.
Most working developers only need a handful of these mappings at a time, but the same set keeps coming up: HTML, CSS, JavaScript, JSON, the common image formats, SVG, and the modern font types. A small, curated reference beats a sprawling copy of the IANA registry for daily use, and it gives you a stable set of values to paste into configuration files that will not shift every time the standards body registers a new subtype.
Look Up a MIME Type by File Extension
When a config asks for a Content-Type value, an allowlist asks which types to accept, or a test fixture asks what an upload should declare, the fastest path is to search the reference directly. The MIME Type Lookup tool runs in your browser, so no file is uploaded and the search text never leaves the page.
- Enter an extension, format name, or media type in the search field. Typing .json, the family image, or a full value such as font/woff2 all narrow the table to matching rows.
- Confirm the matching description and extension aliases. The plain-English label tells you which format the row actually represents, and the alias column flags extensions that share the same registered type.
- Copy the exact base media type and validate it against the real content before use. Paste the copied string into your header, allowlist, or config, then confirm the deployed response or upload handler reports the same value end to end.
For the third step, validation is not optional. A response served by your framework can disagree with the value you configured because of middleware, proxy rewrites, or static file handlers, so the only check that matters is what the client actually sees.
Common File Extension to MIME Type Mappings
The reference anchors a few familiar formats against IANA registration so you can copy a known-good value without leaving the page. The eight rows below are taken from the tool's locked fixtures and align with both the IANA registry and MDN's common-types table.
| Extension | Base media type | Format |
|---|---|---|
| .html, .htm | text/html | HyperText Markup Language |
| .css | text/css | Cascading Style Sheets |
| .js, .mjs | text/javascript | JavaScript module or script |
| .json | application/json | JSON data interchange |
| .png | image/png | Portable Network Graphics |
| .jpg, .jpeg | image/jpeg | Joint Photographic Experts Group image |
| .svg | image/svg+xml | Scalable Vector Graphics |
| .woff2 | font/woff2 | Web Open Font Format 2 |
These eight mappings cover a large share of everyday web traffic, and each one is the value a spec-compliant server should send. If you maintain a static site, a CDN config, or a small API, you can build a working mime.types file from this table alone.
Extensions Are Hints, Not Proof
A filename extension and a real content type are not the same thing, and treating them as the same thing is one of the most common sources of security and correctness bugs in upload pipelines. The MIME Type Lookup tool explicitly ships application/octet-stream as the generic fallback for unknown binary data, with no invented extension attached, because the only honest answer for a blob the server cannot identify is "this is bytes, treat it as untrusted."
The reference documents several real failure modes. A file named picture.png can contain non-PNG bytes, and a browser-supplied File.type can be empty, stale, or derived from the operating system's extension mapping. Secure upload handling therefore has to inspect the content, enforce size and format limits, decode with a safe maintained parser, rename stored objects, isolate them from execution, and apply authorization. None of those steps can be replaced by trusting an extension or a request header, and the same caution applies to a mime lookup you keep open in a tab.
The practical rule is to treat this tool, and the headers and forms that depend on it, as a hint layer that sits on top of a strict allowlist and a content-sniffing step. The lookup helps you pick the right string; your code is responsible for confirming the bytes actually match.
Base Type vs Parameters: What Goes in the Header
A registered media type has a top-level type and subtype separated by a slash, and HTTP headers are allowed to attach parameters after the subtype. Real headers often look like Content-Type: text/html; charset=utf-8 or Content-Type: multipart/form-data; boundary=----abc, but the reference intentionally lists only the base registered type. The copy action places that base value alone on your clipboard, so you decide whether to append charset, boundary, or any other parameter based on the format you are actually serving.
This separation matters because parameters can be wrong as easily as types. Adding charset=utf-8 to application/json is harmless because JSON is text, but appending it to image/png is meaningless and signals confusion. Codecs, transfer encodings, content disposition, and compression are also separate concerns that live outside the media type. Use the base type for routing and allowlists, then add parameters only when the format and the protocol actually call for them.
When the 24-Mapping Reference Is Not Enough
The set is deliberately bounded. Vendor-specific office formats, multipart boundary construction, email transfer encodings, codec parameters, and every obscure registered subtype are out of scope, and the page links to the IANA media types registry and MDN's common media types guide for anything outside the 24 entries. If your project deals with a format that is not in the table, follow the link to the IANA registry and confirm the registered subtype, because the curated set intentionally lags the full registry to stay small and stable.
Some extensions also have historical or contextual alternatives. XML may be served as application/xml in some pipelines, while specialized XML formats have dedicated +xml subtypes such as image/svg+xml or application/atom+xml. JavaScript historically appeared under several legacy values; current web guidance and the IANA registration use text/javascript, which is what the table reports. A .gz file may be labeled with the registered application/gzip or a platform's nonstandard application/x-gzip, and the tool presents one current common mapping rather than pretending every server, registry, or historical browser agrees. For a protocol contract that has to match a specific deployment, recheck the primary registry directly.
For reliable day-to-day use, locate the format in the table, confirm the content bytes truly match it, copy the registered base type, and test the real response or upload path. Treat unknown content as untrusted binary data and prefer an explicit allowlist over accepting every type in this table, because registrations and implementation guidance can evolve independently of any curated reference.