MIME Type Lookup

A short string that tells software what kind of content it is dealing with — image/jpeg, application/json, text/html. It is written as type/subtype: a broad category, then the specific format. Originally invented for email attachments (MIME stands for Multipurpose Internet Mail Extensions), it is now what every HTTP response uses to say what it is returning. The modern spec calls them media types; MIME type is the name that stuck.

Use the lookup above: type the extension and it returns the media type commonly mapped to it. That is a mapping, not an inspection — the tool reads the extension you typed, not the file. To find out what a file actually contains you need to read its bytes, with `file` on Unix, or a content-sniffing library on the server.

image/jpeg — the same for .jpg, .jpeg and .jpe. There is no image/jpg; it is a common guess and servers do not recognise it, so a resource sent with it may be refused or downloaded rather than displayed.

image/png. Animated PNG has its own type, image/apng, but the file extension is still .png and browsers detect the animation from the bytes rather than from the header.

application/pdf. It sits under application rather than text because a PDF is a binary container, not something an editor could usefully open.

application/json. Worth knowing: JSON has no charset parameter — the specification requires UTF-8 — so application/json; charset=UTF-8 is redundant rather than wrong. For JSON-LD the type is application/ld+json, and for a web app manifest it is application/manifest+json.

text/html, normally sent with a charset: text/html; charset=UTF-8. If the charset is missing the browser guesses, and a wrong guess turns non-ASCII characters into mojibake.

text/css. This one has to be right: a browser in standards mode refuses a stylesheet served as anything else, so a misconfigured server produces a page with no styles at all and no obvious error.

text/javascript. RFC 9239 made that the standard value in 2022 and marked application/javascript obsolete. Both still work in every browser, so existing configuration is not broken — but new configuration should use text/javascript. The same value covers .js, .mjs and .cjs.

The media type for JSON data. Sending it tells the recipient to parse the body as JSON; most HTTP clients will then decode it automatically, and most APIs will reject a request body that arrives without it. It is also what a fetch call needs in its Content-Type header when posting JSON.

The media type for an HTML document. It is what makes a browser render markup rather than display it as text — send the same bytes as text/plain and you see the tags instead of the page.

The media type for a JPEG image, covering the .jpg, .jpeg and .jpe extensions. image is the top-level type and jpeg is the subtype, so anything that can handle images generally knows what to do with it even if it cannot decode the specific format.

An extension is part of a filename — a convention for humans and for operating systems deciding which application to open. A MIME type is metadata sent alongside the content, which is how software and network protocols describe it. The important difference is who supplies it: an extension travels with the file and anyone can rename it, while a MIME type is asserted by whatever is serving the content. Neither proves what is actually inside.

The HTTP header carrying the media type of a message body. On a response it tells the client what is being returned; on a request it tells the server what is being sent. It is the single most consequential header for how a browser treats a resource — get it wrong and the browser may download something it should render, refuse a stylesheet, or reject a WebAssembly module outright.

Yes, and .ts is the example that catches people out. It is registered to MPEG transport stream — video/mp2t — which is what a default web server sends for it, and it is also the extension every TypeScript project uses. TypeScript has no registered media type at all. Other cases are milder: .ogg can be audio or video depending on what is in the container.

Routinely. image/jpeg covers .jpg, .jpeg and .jpe; text/html covers .html and .htm; audio/mp4 covers .m4a and .m4b. The media type describes the format, and a format can be spelled several ways in a filename.

No. The type, the subtype and parameter names are all case-insensitive, so Text/HTML and text/html are the same. Convention is lowercase and every tool writes them that way. Parameter *values* are a different matter — a multipart boundary is case-sensitive and must be preserved exactly, which is why this tool lowercases the type but leaves parameter values alone.

A top-level type, a slash and a subtype: image/jpeg is the image type and the jpeg subtype. There are nine top-level types — application, audio, font, image, message, model, multipart, text and video. Subtypes can carry a prefix (vnd. for vendor-specific, x- for unregistered) and a suffix after a plus sign that names the underlying structure, which is what image/svg+xml and application/ld+json are telling you.

Extra name=value pairs after a semicolon, as in text/html; charset=UTF-8. The parameter is not part of the type — the type is text/html, and charset describes how to decode it. The two common ones are charset on text formats and boundary on multipart bodies. This tool splits parameters off before looking anything up, which is why pasting a whole Content-Type header works.

No. The Content-Type on an uploaded file is supplied by the browser, derived from the file extension, and trivially forged by anyone sending the request directly. A file named invoice.pdf carrying a script inside will arrive claiming application/pdf. Validate on the server by reading the actual bytes, keep an allowlist of accepted formats, store uploads outside the web root or on a separate origin, and never let the client decide what a file is.

Because it decides behaviour, not just labelling. A stylesheet sent as text/plain is ignored in standards mode. A WebAssembly module sent as anything but application/wasm is refused by instantiateStreaming. A PDF sent as application/octet-stream downloads instead of opening. And with X-Content-Type-Options: nosniff set — which it should be — the browser stops second-guessing a wrong type and simply blocks the resource.

A response header telling the browser not to guess a resource's type from its content when the declared type looks wrong. Without it, browsers sniff, and sniffing is exploitable — a file uploaded as an image but containing HTML could be executed as HTML. With it, a mislabelled resource is refused instead. The trade-off is that your MIME types then have to be correct, because there is no longer a safety net.

Arbitrary binary data — bytes with no declared meaning. It is the universal fallback, and browsers download it rather than trying to render it. That makes it the safe type for serving untrusted user uploads: whatever is inside, the browser will not execute it in your origin.

Almost always a missing entry in its extension map. Nginx reads conf/mime.types, Apache reads mime.types plus AddType directives, and both fall back to a default — often application/octet-stream — for anything unlisted. Newer formats are the usual casualties: .webmanifest, .wasm, .avif and .woff2 are all missing from older default configs, which is why a font or a manifest silently fails to load.

Yes. Both lookup directions, the search, the reference table and the copy actions are free, with no account and no limit.

No — it never touches files at all. There is no file input; you type an extension or a media type and the lookup runs against a dataset bundled with the page. Everything runs locally in your browser and no lookup value is sent to our server.

The values here are the ones worth sending: standards-based where a standard exists, and the de facto value where that won the argument. But mappings genuinely differ between operating systems, browsers, web servers, registries and applications — .ico is image/x-icon almost everywhere and image/vnd.microsoft.icon in the IANA registry, and both are correct. Where a format has more than one value in circulation, this tool lists them all rather than picking one and hiding the rest.

They describe the same content. RFC 7303 prefers application/xml, because a text/* type implies the body is readable as plain text, which XML generally is not — and because a text/* type without a charset parameter defaults to US-ASCII, which breaks any XML using another encoding. text/xml still works and is still widely sent.

The x- prefix historically marked an unregistered, experimental type: image/x-icon, application/x-tar, text/x-python. RFC 6648 deprecated the convention in 2012 because so many x- types became permanent that the prefix stopped meaning anything. Plenty are still in daily use, which is why this tool resolves them rather than pretending they are gone.

No. A MIME type lookup identifies the media type commonly associated with an extension. It does not prove that a file contains that kind of content — renaming script.js to photo.jpg changes the extension and the type any tool would report, and changes nothing about the bytes. For anything security-sensitive, inspect the content server-side.