MIME Type Lookup

What a MIME type lookup answers, and what it does not

This is a two-way MIME type lookup: type an extension, a full filename or a URL and you get the media type to send, or paste a media type and you get the extensions that carry it. Every answer comes with the header as you would write it — charset included when the type is textual — plus a flag when the string you pasted is one of the obsolete names that survive in copied server configs. One hundred and twenty extensions are mapped here, chosen because they turn up on real web servers rather than because a registry lists them.

What it cannot tell you is what a file really is. A media type is a claim made by whoever served the bytes, and a .png suffix is a claim made by whoever named the file. Neither is evidence. If you need certainty about untrusted input, read the magic bytes; a lookup table is for deciding what to declare, not for verifying what arrived.

The extension is a hint, the header is the contract

On a local disk the extension does the work: it is how your operating system picks an application. Over HTTP the extension is almost irrelevant. The browser reads Content-Type, decides between rendering, downloading and handing the bytes to a decoder, and never looks at the URL to settle it.

That split explains most of the confusion. A file called report.pdf served as text/plain displays as gibberish in the tab. A file with no extension at all served as application/pdf opens in the PDF viewer. Static hosts blur the distinction because they derive the header from the extension, and then the mapping is only as good as the server's own table — which is exactly the table that goes stale.

Two extensions in this list are worth a second look. .ts maps to video/mp2t, an MPEG transport stream, so a server guessing by extension will offer your TypeScript sources to a video player. And .tgz is a double extension where only the final part decides: the type is application/gzip, because the tar archive is inside the gzip container, not beside it.

text/javascript won, and it took fifteen years

For most of the 2000s and 2010s there were three plausible types for a script: application/x-javascript, application/javascript and text/javascript. Style guides told you the text/ one was deprecated. RFC 9239, published in 2022, reversed that: text/javascript is now the registered type, and application/javascript is obsolete.

Nothing breaks either way, because browsers accept a generous list of JavaScript types. It matters anyway for two reasons. Linters and security scanners check against the registry, and nosniff refuses a script served with a type outside that accepted list — so a config that has drifted far enough will fail loudly rather than quietly.

The same tidying happened to fonts. RFC 8081 created the font/ top-level type in 2017, which is why font/woff2 is correct today and application/font-woff2 is the line still sitting in thousands of copied nginx configs.

application/octet-stream is a shrug

application/octet-stream means unknown bytes. It is a fallback, not a description, and it is what this tool returns when nothing in the table matches. Faced with it, a browser saves the file, because rendering something you have declined to identify is how vulnerabilities get written.

Seeing it in production usually means one of three things: the server has no mapping for that extension, an object storage bucket applied its default type at upload time, or a proxy stripped the original header. Setting it deliberately is reasonable for a genuine binary download. Setting it by accident is why a customer reports that your image gallery downloads files instead of showing them.

Sniffing, and the header that stops it

When a type looks wrong, browsers historically sniffed: they inspected the leading bytes and overrode the declared type. Convenient, and a security problem, because a user upload that a server declares as text/plain can be sniffed into HTML and executed against your origin.

X-Content-Type-Options: nosniff turns that off. Send it on everything, then make sure your types are right, because with sniffing disabled a wrong type stops being cosmetic. Two rules go with it for anything users upload: serve from a separate origin, and never serve user files as image/svg+xml, since SVG is markup that can carry script.

Every extension in the table

The names that were never right

None of the strings on the left is the registered name today, and every one of them is somewhere in a configuration file being copied right now. Browsers tolerate all of them, which is precisely why they persist; the cost lands on the next person to inherit the config, and on any validator, gateway or CDN rule that matches types exactly.

Where this fits

A wrong media type usually shows up first as a status code that makes no sense — a 415 on an upload, or a 406 from content negotiation — and the HTTP status codes reference says what each of those is really complaining about. When the argument is about the path that produced the header rather than the header itself, the URL parser splits a request target into the pieces the server matches on. And when a type arrives attached to an inline payload, the Base64 encoder and decoder is the quickest way to see what a data: URI is actually carrying.

The table above is compiled into this page, so the lookup works with the network off. Your input never leaves the tab.