What MIME Type Lookup does
A MIME type is how a server tells a browser what kind of file it is sending, and browsers trust that header over the file extension entirely. Get it wrong and a stylesheet is ignored, a font fails to load, or a PDF downloads instead of opening. Search here by extension or by type to get the correct value, the exact Content-Type header to send, and whether the type is text-based and therefore needs a charset. The distinction between text and binary types is the one that causes most encoding bugs, so it is called out explicitly rather than left implied.
How to get your result
- 1
Enter a file extension such as webp, or a MIME type such as application/json.
- 2
Read the detail panel for the exact Content-Type header to configure.
- 3
Check whether the type is text-based — if so, append a charset.
- 4
Browse the table for related types when you are configuring several at once.
When you would reach for this
Fixing a font that will not load
Fonts served with the wrong type are rejected by the browser, and the console error is often unhelpfully vague.
Configuring a web server or CDN
Newer formats such as webp, avif and wasm are missing from older server configurations and default to a generic binary type.
Setting an upload allowlist
Knowing the correct type for each format you accept is the starting point, though the type a client reports must never be trusted on its own.
Building an API response
Returning application/json rather than text/plain is what makes clients parse the body automatically.
Why the header beats the file extension
Browsers decide how to treat a response from the Content-Type header, not from the URL. A file called styles.css served as text/plain is not applied as a stylesheet, and an ES module served as anything other than a JavaScript type is refused outright with a strict MIME check error. This is deliberate: extensions are part of a URL and can say anything, while the header is a statement by the server about what it is actually sending. It also explains the single most common symptom people hit, where a file downloads instead of displaying — that is application/octet-stream, the generic 'unidentified binary' type, telling the browser it has no idea what this is and cannot render it. There is one important exception to the browser trusting the header, which is that a response with X-Content-Type-Options: nosniff turns off the browser's fallback content sniffing, making a wrong header fail loudly rather than being silently corrected.
Charsets, and why upload validation cannot rely on this
A charset parameter tells the browser how to turn bytes into characters, and it belongs only on text-based types. Omit it on an HTML page and the browser may fall back to a legacy encoding, rendering accented characters and emoji as mojibake — which is why text/html; charset=utf-8 is the standard value. Binary types have no character encoding at all, so a charset on an image or a PDF is meaningless. The security caveat is worth stating plainly: the MIME type a browser reports when a user uploads a file is derived from the extension on the client machine and is trivially forged. A server that validates uploads by checking the reported type will happily accept an executable renamed to holiday.jpg. Real validation inspects the file's actual bytes — the magic number at the start — and, for images, confirms the file genuinely decodes as one.
Practical notes
- Always send charset=utf-8 on HTML, CSS, JavaScript, JSON and plain text; never on images, fonts, video or PDFs.
- If a file downloads instead of displaying, check for application/octet-stream or a Content-Disposition: attachment header.
- Never trust the MIME type reported by the client on an upload — validate the file's actual contents on the server.