搜索常见文件扩展名及其 IANA MIME 类型对照表，支持按顶级类别筛选，帮助你每次都设置正确的 Content-Type 响应头。
这个文件该用哪个 Content-Type 响应头？ 输入 .webp 这样的扩展名，或 image 这样的媒体类型片段来筛选表格。所有条目均依据 IANA 媒体类型注册表和 MDN 常见类型清单。
没有扩展名或媒体类型匹配该搜索。
MIME 类型——正式名称是媒体类型——是服务器附加在响应上的标签，让客户端知道随后的字节该如何处理。它由斜杠分隔的两部分组成：顶级类型，例如 text、image、audio、video、font、model 或 application；以及指明具体格式的子类型。image/png 和 application/json 都是完整的媒体类型，而单独的 image 不是。
子类型自身也有一些约定。开头的 x- 曾用于标记实验性类型，例如 application/x-tar；虽然这种做法已被废弃，但沿用下来的名称部署过于广泛，无法更改。结尾的 +后缀 表示该格式建立在更通用的语法之上：image/svg+xml 是 XML，application/ld+json 是 JSON，解析器在不认识具体格式时可以回退到基础语法。
有些类型允许在分号后附加参数，其中最重要的是 charset，例如 text/html; charset=utf-8。在文本响应中省略它等于邀请浏览器去猜测编码，这是乱码的经典成因，因此显式声明 UTF-8 永远值得多写这几个字符。
浏览器根据 Content-Type 响应头而不是 URL 中的文件名来决定如何处理响应。把 PNG 当作 text/plain 发送会显示一屏二进制乱码；把 JSON 标为 text/html 可能导致 fetch 客户端拒绝它。响应头正确，下载才会用正确的应用打开，内联资源才会渲染而不是被下载。
这种不匹配还有安全后果。老式浏览器会进行 MIME 嗅探：检查响应的前若干字节，并覆盖它认为错误的响应头。攻击者只要能上传一个看起来像 HTML 的文件，即使服务器把它标为图片，也可能让它在站点源下执行。X-Content-Type-Options: nosniff 响应头可以关闭该行为，如今在任何提供用户上传内容的端点上都是标准做法。
对于下载场景，请把媒体类型与 Content-Disposition: attachment; filename="report.pdf" 搭配使用。媒体类型描述这些字节是什么，disposition 描述浏览器应该拿它们做什么，二者回答的是不同的问题。
并不存在一份唯一权威的扩展名到类型的对照表，这一点常令人意外。IANA 注册的是媒体类型本身，而从文件扩展名到类型的映射是各服务器各自维护的本地约定。Apache 读取 mime.types，nginx 有自己的 mime.types 文件，应用框架也各自携带查找表。这就是同一个 .wasm 文件在一台服务器上被正确提供、在另一台未更新的服务器上却变成 application/octet-stream 的原因。
application/octet-stream 是通用兜底值，含义是「任意二进制数据」。当格式确实未知时它是诚实的答案，但它会让内联渲染失效，因此值得为站点经常提供的每种格式补上显式映射。AVIF、JXL 和 WebAssembly 这类较新的格式，正是老旧服务器配置中最常缺失的条目。