MIME Types: What Content-Type Actually Controls

A file extension is a naming convention. A MIME type is a declaration that tells the browser or the server how to interpret the bytes. When a stylesheet loads as text/plain, the browser may refuse to apply it. When an API response is labeled text/html, a fetch call can parse it as text or reject it. Most of the time the mapping is automatic, which is why the failures feel mysterious when it is not.

Part of the developer toolkit guide. Use the local MIME type lookup to move between common extensions and their registered types, then read the caveats below before treating the result as a server configuration.

What a MIME type actually contains

A MIME type has a top-level type and a subtype, separated by a slash: text/html, image/svg+xml, application/json. It can carry parameters such as charset=utf-8 or a multipart boundary. The Content-Type header on an HTTP response is the server's statement about the body. A <meta charset> tag or an HTML attribute can influence parsing, but the header usually wins for the initial response.

Type names are case-insensitive, although lowercase is conventional. The subtype can carry a structured-syntax suffix, as in application/ld+json or image/svg+xml. That suffix signals a structured syntax rather than a different top-level category. A server that does not recognize a suffix may still serve it correctly if the client understands the base type.

There is no universal registry lookup in the browser. The operating system, the web server, the framework and the CDN each carry their own table. That is why a file can have the right extension and still arrive with the wrong header. Diagnose the header, not just the file name.

How the lookup tool behaves

The tool contains a small built-in table of 44 common extensions and their types. It accepts an extension with or without a leading dot, lowercases the input and returns both sides of the mapping. It also accepts a MIME type and searches for the first matching extension. For example, json and .json both return application/json, while application/json returns .json.

Reverse lookup is not one-to-one. image/jpeg maps to both jpg and jpeg; the tool returns the first entry it encounters, which is jpg. text/javascript maps to js and mjs, and returns js. If you need a specific extension, use the extension-to-type direction instead of assuming the reverse is unique.

The table covers documents, images, audio, video, archives, fonts and a few application formats. It does not include every registered type, vendor-specific types, parameters such as charset, or structured suffixes beyond the ones in the table. An unknown value returns an informational no-match message. That is a limitation, not a statement that the type is invalid.

Serving assets with the right type

Static hosts usually infer the type from the extension. Dynamic frameworks may set it from a route handler or a file response helper. The failures cluster around a few patterns. A JavaScript module served as text/plain is blocked because module scripts require a JavaScript type. A CSS file served as text/html is ignored under strict MIME checking. A JSON endpoint served as text/html can still be read as text, but a client that expects JSON may parse it differently or reject it.

Fonts are another common case. A font served with the wrong type may fail to load, and a cross-origin font request also needs the right CORS headers. The MIME type alone does not grant permission. Check both the Content-Type and Access-Control-Allow-Origin values when a font or module fails only on a different origin.

SVG deserves separate treatment. It is an image type, but an SVG file is also XML and can contain scripts and external references. Served as image/svg+xml and loaded through <img>, scripts generally do not run. Inlined into the page or loaded as a document, the security model changes. Treat user-uploaded SVG as untrusted markup, not as a harmless picture.

Content-Type is not a security boundary

A browser may sniff the body and override a vague or missing type. X-Content-Type-Options: nosniff disables that behavior for many responses and makes a wrong type fail loudly instead of being guessed. That is usually desirable for scripts and styles, but it raises the cost of misconfiguration. Set the header deliberately and test the site after enabling it.

On uploads, the client-supplied type is a hint, not proof. An attacker can name an HTML file photo.jpg and send image/jpeg as the type. Validate the actual bytes, re-encode images where possible, store uploads outside the web root or serve them with Content-Disposition: attachment when they are not meant to render. Never rely on the extension alone.

For APIs, declare application/json and reject unexpected content types on write endpoints. Accepting text/plain because a proxy rewrote the header hides a real configuration problem. Log the received type when debugging, but do not echo it back without validation.

Debugging a MIME problem

1. Open the network panel and read the response Content-Type, not the file extension.
2. Check the server or CDN rule that sets the header for that path or extension.
3. Confirm the file is not being served by a fallback route that returns HTML for missing assets.
4. Look for a proxy, service worker or build step that rewrites the response.
5. Test with a direct request such as curl -I to separate browser behavior from server behavior.
6. After changing the rule, purge the CDN cache and retest in a fresh tab.

A 404 disguised as a MIME error is common in single-page apps. The server returns the app shell with text/html for a missing script, and the browser reports a type mismatch. The real fix is the missing file or the route fallback, not the MIME table.

Limits of a small lookup table

The tool is a quick reference, not an authoritative registry. It will not resolve newer or vendor-specific types, and it does not tell you which type a particular server will send. Use it to check a familiar mapping, then verify the live header. For standards work, consult the IANA media types registry and your server's documentation. For a file you are about to publish, test the actual response from the actual host.