MIME Type Reference

MIME type categories

MIME types are grouped into registered top-level categories such as application, audio, font, image, model, multipart, text, and video, and each one describes a different class of content that a browser or client knows how to interpret.¹ The category prefix in a MIME string tells you, at a glance, whether you are dealing with data, media, text, or a composite message.

The two words in play name two different things. The MIME type is the registered media type name itself, the string this database is built from, while Content-Type is the HTTP header field that carries that name on every request and response.² After the type itself, parameters can ride along, separated by a semicolon, and the most familiar is charset=UTF-8 on text responses, telling the receiver how to decode the bytes that follow the name. When a server or framework asks you to set a content type, the value it expects is the media type string, optionally with a parameter attached.

Media and document types

application/ is the largest category, covering structured data, executables, archives, and API payload formats ranging from JSON and PDF to ZIP archives and WebAssembly. By contrast, audio/ and video/ cover time-based media: audio/mpeg, Opus, AAC, FLAC, and WAV are the most common audio containers, while MP4 with H.264 remains the most compatible web video format and WebM serves as the open alternative.

image/ covers still images and vector graphics, where AVIF and WebP offer the best compression for modern browsers and SVG (image/svg+xml) is the standard for scalable vector artwork. Because the image category spans both raster and vector formats, choosing the right MIME string matters when you are configuring server caching headers or setting up content negotiation for responsive image delivery. Serving an AVIF file as image/jpeg, for instance, gives the browser bytes that contradict the label, and what happens next varies by browser: some sniff the real format and render anyway, while others trust the label or the file extension and can leave the image broken.³

Fonts, models, text, and composites

For downloadable fonts, font/ is the category to check: WOFF2 (font/woff2) is the preferred format because it uses Brotli compression and is supported by all modern browsers,⁴ while the older EOT format (application/vnd.ms-fontobject) is deprecated. Older registrations like application/font-woff and application/font-sfnt have also been moved into the font/ top-level type under RFC 8081, which reorganized font media types into their own category to avoid mixing them with generic application/ types.⁵

The remaining categories serve more specialized roles. model/ covers 3D scene and geometry formats such as glTF, GLB, STL, and USDZ, while text/ groups human-readable formats with specific syntax like HTML, CSS, CSV, and Markdown. Finally, multipart/ covers composite messages: multipart/form-data is required for HTML file uploads,⁶ and multipart/byteranges appears in 206 Partial Content responses.²

The fallback type: application/octet-stream

One entry in the database deserves its own explanation. application/octet-stream declares a body of raw bytes with no claimed format, and it reaches your users through two different doors. When a server has no mapping for a file's extension, it sends the resource as this generic type, which is how most web servers handle unrecognized files.³ On the receiving end, a browser treats the opaque type as unknown binary data and offers a save dialog rather than attempting to render it, because the declared type promises nothing about the bytes it labels.

The two reader goals point in opposite directions. Deliberately serving a file as octet-stream forces a download for any file without mislabeling its real format, a clean way to hand out documents you want saved rather than opened in a tab. Accidentally serving it is the opposite problem: the file that downloads when it should render, the font that never loads, the resource that breaks a page. The fix is not renaming the file but adding its extension's real mapping, and the config snippets in each detail panel are the exact lines to add.

Inside multipart/form-data

An HTML form carrying a file input takes a different shape on the wire. The browser sends it as multipart/form-data with a generated boundary parameter, and every form field and file becomes its own part inside the request body, each part carrying its own headers.⁶ Inside the same envelope, a plain text field and a 4 MB upload travel as siblings, separated by a delimiter built from the boundary string, which is why the type appears where form submission does and never in a response from a static file server.

That structure explains why you will never find it in a server's types table. multipart/form-data is a request-body structure the browser builds, not a file type a server serves, so no static extension mapping can point at it. Because the boundary value differs per request, generated fresh for each submission, no fixed table entry could match it even if one tried. Servers that accept uploads read the boundary parameter from the request's Content-Type header and split the parts on the delimiter it names, which is the mechanism the whole upload path depends on.

Server configuration

Web servers ship with a built-in MIME type table that covers most common types, but you still need to add explicit configuration when serving newer formats such as WebAssembly, modern image formats like AVIF and WebP, WOFF2 fonts, and 3D assets like glTF. Without those entries, the server falls back to a generic Content-Type and the browser may refuse to handle the file correctly.

Nginx and Apache

In Nginx, you add or override entries with a types block placed inside http {} or server {}, and the snippet format shown in each detail panel is the exact directive to paste into that block.⁷ In Apache, the equivalent is the AddType directive, which works in httpd.conf, a virtual host config, or a per-directory .htaccess file.⁸ Both servers merge custom entries with their built-in table, so you only need to declare the types that are missing or that you want to override.

A concrete mapping ties the abstract rule to a real config line. The .wasm extension maps to application/wasm, the type IANA registers for WebAssembly binaries.⁹ Adding it to an Nginx types block looks like types { application/wasm wasm; } placed inside the http {} or server {} block covering your site. Apache's equivalent is a single line, AddType application/wasm .wasm, dropped into httpd.conf, a virtual host block, or a per-directory .htaccess file.

Caddy

For Caddy v1, the mime directive maps an extension to a MIME type directly inside the Caddyfile, which keeps the rule visible alongside the rest of your site configuration. The snippets shown for Caddy use this exact format,¹⁰ so you can paste them in without renaming variables or adjusting paths. Caddy v2 handles MIME types differently through its HTTP app configuration, but the snippets provided here target the v1 directive syntax that many existing deployments still rely on.

Setting the type in application code, then verifying it

The config file is only one layer of the answer. In application code, the response's type is set by a Node handler, a Python route, or a framework's response object, and a fronting proxy can transform it again before it reaches the browser, so whichever layer touches the response last decides the header the visitor sees. Framework code sets the value through its response-header interface, and the string it expects is exactly what the search box above returns: the media type name, with a parameter if the content needs one.

After any change, read what the server actually sends. The Content-Type response header is visible in the browser DevTools Network tab for every request a page makes, and a single request from a terminal or any HTTP client returns the header for one address, which is the whole observation step. A mapping that looks configured can still be overridden downstream, by the framework layer or a proxy, which is why the observation comes after the configuration rather than instead of it. This reference is the lookup for what the header should say: it does not fetch URLs or test servers itself.

Deprecated types

Several MIME types have been formally superseded or aligned with newer registrations as the web platform has evolved. The most common cases you will encounter are application/javascript and application/ecmascript being replaced by text/javascript under RFC 9239,¹¹ text/xml aligned as an alias for application/xml under RFC 7303,¹² and image/x-icon, which Microsoft software itself uses for ICO files even though image/vnd.microsoft.icon is the IANA-registered type.¹³

EOT fonts (application/vnd.ms-fontobject) are another deprecated family, and every major browser implements WOFF2, so serving EOT adds no value for any modern user agent.⁴ Deprecated entries in this reference are marked with a yellow warning banner in the detail panel, and each one links to the spec that documents the recommended replacement so you can update your server configuration with confidence and avoid serving stale types to modern browsers.

MIME types and browser security

Browsers treat MIME types as part of their security model. WebAssembly binaries must arrive as application/wasm or the browser refuses to compile them, producing a hard error with no fallback.⁹ Web fonts loaded from a different origin require a permissive Cross-Origin-Resource-Sharing header, or the browser silently rejects them and the page falls back to system fonts.¹⁴ Both restrictions force an explicit guarantee before the browser acts: a matching declared type for WebAssembly, an explicit opt-in from the server hosting the font. Scripts served without a recognized JavaScript MIME type will not execute when the response carries X-Content-Type-Options: nosniff.¹⁵

The X-Content-Type-Options: nosniff response header reinforces your declared MIME type. Without it, a browser may detect executable content inside a file and act on that detection regardless of what Content-Type says. Setting nosniff tells the browser to trust your declared type exactly. Combining a correct Content-Type with nosniff closes the gap between what you declare and what the browser assumes. CapyToolkit's server config snippets already include nosniff in the recommended directives for file types where this protection matters most.¹⁵