Your build passes locally and the page renders on your laptop, yet a user in another region opens it and the WebAssembly module will not run. The file is identical. What changed is the Content-Type header the server sent, and most teams never notice the mismatch until a support ticket describes a download that should have executed or an image that should have displayed. These failures stay silent because the browser enforces declared MIME types for module scripts, WebAssembly, and fonts with zero tolerance, so a wrong type does not degrade gracefully, it simply fails. You can resolve the question before it ships by looking up the exact MIME type for a file, extension, or keyword and copying a correct server directive, all without uploading anything to a third party.
Why the Wrong MIME Type Breaks Things Silently
Browsers enforce the declared MIME type for module scripts, WebAssembly, and fonts with zero tolerance.1 That enforcement is part of the security model rather than a convenience you can switch off, so when the type is wrong the asset does not downgrade to something close, it fails outright while the rest of the page keeps loading as if nothing happened. Silence is the real cost.
The broken shapes are easy to recognize once you have seen them. A .wasm served as application/octet-stream never instantiates, an image/avif served as text/plain triggers a download instead of rendering, and a font/woff2 returned without the right cross-origin headers falls back to a system face.2 An API response with the wrong type can make a strict client, a service worker, or a CSP script-src rule mishandle or reject the payload entirely. The shapes are familiar now.
The reason these bugs feel invisible is that your dev server usually gets the type right, which hides the defect through the whole review cycle. It surfaces only when a bare Nginx or a CDN node serves the same file with a default mapping, by which point the asset is cached and the report comes from a user instead of your test suite. When the server sends no type, the browser may fall back to MIME sniffing the bytes, which varies per browser and has itself been a security hole. A correct Content-Type is the cleanest fix.
How the Browser MIME Type Reference Tool Works
CapyToolkit’s MIME Type Reference runs entirely in your browser, with no backend and no upload step anywhere in the flow. You type a full string like application/json, a bare extension like .wasm, or a keyword like “protobuf” into the search box, and the tool queries its local database so nothing you type leaves your machine. The database is built from the IANA registry, which means the results match what a compliant server expects rather than a hand-curated guess list. The lookup stays local.
The interface groups every type under category pills: Application, Audio, Font, Image, Model, Text, Video, and Multipart. Click any entry to expand its Details panel, which shows the governing spec, a plain description, and ready-to-paste server configuration for Nginx, Apache, .htaccess, and Caddy. One click copies the directive to your clipboard.
Because the lookup is client-side, you can use the browser-based reference to look up the exact MIME type for any file, extension, or keyword directly in your browser and still keep proprietary files on your own disk. The reference is one of several browser-based tools from CapyToolkit that process everything locally, which matters the moment the file you are identifying is proprietary. The tool hands you the answer and the deployment snippet in one place, which is the whole point when you are staring at a broken asset at 2 a.m.
Looking Up a MIME Type by File Extension, Keyword, or Full String
When auditing local assets, searching by file extension offers the fastest path to clarity. By typing a simple extension like .wasm, you instantly retrieve application/wasm alongside its governing specification and a copy-ready server snippet, and the same works for obscure extensions you have never seen in a config file. Start there, because it eliminates the guesswork on formats you have never configured.
Keyword search covers the cases where you know the format but not its registered type. “avif”, “webp”, “protobuf”, and “event stream” all resolve to the correct media type and its serving requirements, so you stop guessing and start reading the authoritative mapping. Browsing by category surfaces types you did not know existed, from model/ machine-learning formats to multipart/ payloads, and makes it easy to confirm the modern replacement for a legacy type. The list exposes gaps.
Search by extension
Search by extension is the move when you already have a filename. Paste .wasm and you get application/wasm, which streaming WebAssembly compilation requires exactly as written, and paste .mjs or .js to get the JavaScript type with the RFC 9239 correction we cover later. Extensions that look similar can still map to different types, so confirm the result rather than assuming, because a .mjs module and a classic .js file both run JavaScript yet interact with ES module strictness in ways the browser enforces. The extension decides.
Search by keyword
Keyword search is for format-first thinking. Type “avif” or “webp” to get the modern image types that silently downgrade to a download when mislabeled, or type “event stream” to get text/event-stream for Server-Sent Events endpoints. It also catches the formats people misremember, resolving “wasm” or “web assembly” to the single correct type so a wrong guess never reaches a config that a strict browser will later reject. Keywords spare the guess.
Browse by category
The Application and Font categories collect the types most often mis-served in production: JSON, WASM, and web fonts. Walking those groups is the quickest way to spot a gap in your own server map before a user reports a broken asset, and it turns a flat lookup into a checklist you can audit against your deployment.
Font types deserve special attention here, because cross-origin loading adds a CORS requirement on top of the MIME type. A font/woff2 file with the right type but missing Access-Control-Allow-Origin still fails, so the Font category is where you confirm both halves of the requirement instead of shipping a header that looks correct but is not.
To audit your server’s current output quickly, the index below maps common production assets to their canonical media types:
| Use case | Correct MIME type | Reference |
|---|---|---|
| REST API response or JSON file | application/json | the standard API content type |
| Modern raster image | image/avif or image/webp | image/avif reference |
| WebAssembly module | application/wasm | application/wasm reference |
| Web font | font/woff2 | font/woff2 reference |
| HTML file upload | multipart/form-data | multipart/form-data reference |
| Server-Sent Events stream | text/event-stream | the streaming response type |
Where MIME Types Get Misconfigured on Real Servers
Stock server MIME maps are years out of date, because the mapping file ships with the server and only changes when the distro maintainer updates it. Most shipped before image/avif and application/wasm were even registered, so a default Nginx or Apache build serves both as application/octet-stream and breaks them in production. This is not a corner case, it is the default state of a freshly installed web server until you touch its config.
This mismatch stems from a structural lag between slow release cycles and evolving web specs. Because distro maintainers freeze the system media maps at release time, long-term-support images shipped before IANA registered image/avif3 and application/wasm4 in 2021 lack native records for those extensions. A server installed from one of those older images falls back to octet-stream. The map is stale.
The copy-paste config the tool generates
The reference tool closes that gap with copy-paste directives you can drop into a live config. The block below is the corrected mapping for the two types most often missing from stock configs, and if your server already declares one of these types you should merge the line rather than pasting the block twice. Merge, never duplicate.
# Nginx: add inside the http { } block
types {
image/avif avif;
application/wasm wasm;
}# Apache: via mod_mime
AddType image/avif .avif
AddType application/wasm .wasm# Caddy: declare globally at the top of your Caddyfile
{
mime .avif image/avif
mime .wasm application/wasm
}Paste each block into the right scope. The Nginx types block lives inside http {}, Apache AddType lines belong in a mod_mime context or your .htaccess, and Caddy’s mime option lives in the global block at the top of your Caddyfile. Run nginx -t or apachectl -t, then confirm with curl -I before you trust the change in production.
Common misconfigurations
Placing these directives in the correct scope aligns your server with current standards, yet minor oversights during deployment can still trigger quiet failures at the CDN edge. The usual mistakes are predictable. AVIF and WASM land as octet-stream, web fonts come back without Access-Control-Allow-Origin, and your web server maps .mjs to the wrong JavaScript type, so after deploying you should verify with curl -I https://your-domain/file.wasm and confirm the Content-Type header before you trust a CDN cache that may have already frozen the wrong value. Verify against the origin, not just the local server, because a header that reads correctly on your box can still be wrong at the edge if the CDN overwrote it during delivery.
Validating File Uploads With the Right Content Type
The name lies. The browser derives client-side File.type from the file extension, not its bytes, so a renamed .exe can report image/png and trusting that field as validation opens your server to malicious uploads. The browser tells you what the file is named, not what it contains, and an attacker who controls the filename controls that field completely.
Real safety means checking the type on the server against magic bytes, while still using the correct multipart/form-data envelope on the client so the payload arrives intact. The client envelope and the server check solve different problems, and confusing them is how insecure upload handlers get written in the first place. Looking up the expected type locally first lets you write both the client form and the server check against the right media type, and keeps any private sample file on your own machine. Trust the bytes.
The client-side check still earns its place, just not as a security boundary. Reading File.type lets you warn a user the instant they pick a .png that is really a .exe, which saves a needless upload, and you should treat that warning as UX while the server’s byte inspection makes the actual accept-or-reject call. Doing the lookup before you build means the test files never leave your desk. Warn, then verify.
Deprecated and Dangerous MIME Types to Stop Serving
A handful of once-common types are now formally obsolete. text/xml, application/ecmascript, and image/x-icon should be replaced with their modern equivalents, and each one lingers in old configs because nobody audits the type map after the first deploy. The JavaScript type deserves special care, because per RFC 9239, published in 2022, text/javascript is the registered, canonical ECMAScript media type and application/javascript is now an obsolete alias that browsers and servers must still accept for backwards compatibility.5
This corrects the reverse claim that many configs and even some tool pages still repeat. Serve text/javascript for both classic scripts and ES modules, and you can read the RFC 9239 specification that makes text/javascript canonical for the register’s exact wording.5 The pattern repeats across older formats, where text/xml gives way to application/xml6 and image/x-icon should move to image/vnd.microsoft.icon7 or simply be served with the non-prefixed type modern browsers accept.
Audit your server’s type map against the deprecated list and remove obsolete entries before they trigger browser warnings or blocked executions. Cleaning the map is a ten-minute job that removes a whole class of future breakage, so fold it into the same change where you add the new AVIF and WASM lines rather than leaving it for a later sprint that never arrives. Clean it once.
Browser Security: MIME Sniffing and nosniff
MIME sniffing is the browser guessing a type from content when the declared one looks wrong. It has been a historic cross-site scripting and content-injection vector, which is why X-Content-Type-Options: nosniff exists to tell the browser to accept the declared type and stop guessing. The MDN guide to MIME types covers why browsers sniff and when they stop, which is worth reading before you argue the header is optional. Sniffing is the risk.
Sending correct, specific MIME types is therefore a security control, not just correctness. It lets nosniff do its job and lets a tight Content-Security-Policy script-src enforce strict loading, and when the type is exact the policy engine blocks a script that arrives with the wrong label instead of guessing.1 The MDN reference for X-Content-Type-Options documents the exact header and its one accepted value, nosniff, so you can wire it into every response your server sends.8
The classic exploit is a user upload. An attacker posts a script disguised with an image extension and a text/plain or missing type, and without nosniff the browser sniffs the bytes, decides it is JavaScript, and executes it from your origin.8 Correct types plus nosniff collapse that entire class of attack, because the browser never reclassifies the response in the first place.
A Local-First Workflow for Getting MIME Types Right
The loop is simple. Look the type up in the browser reference, copy the matching server directive, deploy it, then verify with curl -I and fix any mismatch, and you do all of it without uploading a single file to a third-party service, which keeps proprietary binaries and private uploads on your own machine.
Keep the habit client-side. A correct MIME type is a one-line config win, and resolving it locally means the files that matter most never leave your desk. CapyToolkit offers a set of browser-based tools that process everything locally, and the MIME reference is the one to reach for the next time an asset breaks in production. Treat it as a five-minute habit you run whenever you add a new asset type, and the broken-download tickets stop showing up in your queue.
- Identify the target file: pin down its expected media type before you touch any server configuration.
- Look it up by extension or keyword in the local reference.
- Deploy the code: apply your copied Nginx, Apache, or Caddy directive, then reload the server.
- Verify the
Content-Typeheader withcurl -I, and re-test the failing asset in a real browser.
- 1.
WHATWG, “MIME Sniffing,” whatwg.org, March 2026. https://mimesniff.spec.whatwg.org/
- 2.
Mozilla Developer Network, “WebAssembly.instantiateStreaming(),” developer.mozilla.org, May 2025. https://developer.mozilla.org/en-US/docs/WebAssembly/Reference/JavaScript_interface/instantiateStreaming_static
- 3.
“Media Type Registration: image/avif,” iana.org, January 2021. https://www.iana.org/assignments/media-types/image/avif
- 4.
“Media Type Registration: application/wasm,” iana.org, April 2021. https://www.iana.org/assignments/media-types/application/wasm
- 5.
M. Miller, M. Borins, M. Bynens, and B. Farias, “Updates to ECMAScript Media Types,” RFC 9239, IETF, May 2022. https://datatracker.ietf.org/doc/rfc9239/
- 6.
H. Thompson and C. Lilley, “XML Media Types,” RFC 7303, IETF, July 2014. https://datatracker.ietf.org/doc/rfc7303/
- 7.
Mozilla Developer Network, “Image file type and format guide,” developer.mozilla.org, accessed June 2026. https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Formats/Image_types
- 8.
OWASP Foundation, “HTTP Security Response Headers Cheat Sheet,” owasp.org, accessed June 2026. https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html
