MIME 类型速查表 - Content-Type 文件类型大全
Content-Type 配错往往是"下载乱码、页面变形、上传被拒"这类隐形 bug 的真凶。本表按文件类别组织，把每个媒体类型对应的扩展名、正确的 Content-Type 字符串和字符集提示放在一起，覆盖从 text/html 到 application/json、以及 .wasm、.woff2 这类容易被 Nginx 默认挡掉的类型。帮你在配置 mime.types、设置后端响应头、校验上传时一把查到位。
典型使用场景
面向写 HTTP 响应、静态资源服务、文件上传与下载逻辑的开发者。MIME type 决定浏览器怎么处置一个响应：标成 text/html 就渲染，标成 application/octet-stream 就下载。本表按类别收录 47 个常用类型——文本、图片、音视频、字体、办公文档、压缩包——以及三个最容易被忽略的：text/event-stream（SSE）、application/wasm（WebAssembly）与 application/ld+json（SEO 结构化数据）。文件上传时还有 multipart/form-data 这一条边界规则。
文本类型 8
text/htmltext/csstext/javascripttext/plaintext/xmltext/csvtext/markdowntext/event-stream图片类型 7
image/jpegimage/pngimage/gifimage/svg+xmlimage/webpimage/avifimage/x-icon音视频类型 7
audio/mpegaudio/wavaudio/oggaudio/aacvideo/mp4video/webmvideo/quicktime应用与数据类型 9
application/jsonapplication/xmlapplication/javascriptapplication/octet-streamapplication/x-www-form-urlencodedmultipart/form-dataapplication/wasmapplication/graphqlapplication/ld+json文档类型 6
application/pdfapplication/mswordapplication/vnd.openxmlformats-officedocument.wordprocessingml.documentapplication/vnd.ms-excelapplication/vnd.openxmlformats-officedocument.spreadsheetml.sheetapplication/vnd.openxmlformats-officedocument.presentationml.presentation压缩类型 6
application/zipapplication/gzipapplication/x-tarapplication/x-bzip2application/x-7z-compressedapplication/x-rar-compressed字体类型 4
font/wofffont/woff2font/ttffont/otf参数矩阵
| 参数 | 作用 | 示例 |
|---|---|---|
Content-Type 响应头 | 决定浏览器渲染还是下载，写错会直接把页面变成下载或显示源码 | text/html :: .html HTML 文档 |
text/* 与 image/* 前缀 | 按大类选择类型；text/event-stream 用于 SSE 而不是普通轮询响应 | text/event-stream :: SSE 服务器推送事件流 |
application/octet-stream | 二进制默认类型，用它强制浏览器下载而不是尝试渲染 | application/octet-stream :: 二进制流（默认下载） |
multipart/form-data | 表单文件上传的类型，请求体被 boundary 分段，必须带 boundary 参数 | multipart/form-data :: 文件上传 |
vnd.openxmlformats-* 系列 | 新版 Office 文档的正式类型名，与旧的 msword/vnd.ms-excel 并存 | application/vnd.openxmlformats-officedocument.wordprocessingml.document :: .docx Word 文档（新） |
字体类型 | @font-face 加载字体时用 font/woff2 优先，回退 woff 或 ttf | font/woff2 :: .woff2 WOFF2 字体 |
易错点与避坑指南
现象接口返回 JSON，浏览器却弹窗问「是否保存文件」。
原因响应头写成了 application/octet-stream 或没写 Content-Type，浏览器按二进制下载处理。
处置改成 application/json，并确认 CORS 响应里的 Content-Type 在 exposed headers 中可见。
现象上传接口报「缺少 boundary」或服务端解析不出文件。
原因手写 multipart/form-data 头时漏掉 boundary 参数，body 里也没有对应的分隔标记。
处置不要手写，直接用 FormData 配合浏览器/框架自动生成的 boundary。
现象SVG 图标在浏览器里渲染成空白或被当成文档独立打开。
原因image/svg+xml 属于可执行文档类型，带内联脚本时浏览器会执行它。
处置对外提供 SVG 时剥离脚本，或改用 PNG/字体图标。
现象.docx 下载后打不开，或 Office 报「文件格式与扩展名不一致」。
原因把新版 docx 标成了旧类型 application/msword，扩展名与实际容器格式对不上。
处置按本表选对应的 vnd.openxmlformats-officedocument.* 类型，不要套用旧 msword。
排障路径
1看某个 URL 实际返回的 Content-Type
curl -sI https://example.com/app.js | grep -i content-type与本表中的 text/javascript 对照，不一致就会被浏览器当下载处理。
2用本表类型给文件推断 Content-Type 并比对
file --mime-type data.json输出 application/json，与表中 application/json 一致即可放行。
命令示例
用 file --mime-type 推断本机文件的类型
file --mime-type package.json nuxt.config.tsfile 靠魔数（magic number）判断而不是扩展名，所以改错了扩展名也能给出真实类型，正好用来核对表里的映射是否对得上。
输出
package.json: application/json nuxt.config.ts: text/javascript
Python 标准库按扩展名给出 MIME 类型
python -c "
import mimetypes
for e in ['a.json', 'a.svg', 'a.wasm', 'a.csv', 'a.md']:
print(e, '->', mimetypes.guess_type(e)[0])
"guess_type 只查扩展名映射表，不读文件内容。表里没有的扩展名它会返回 None，此时退回 application/octet-stream。
输出
a.json -> application/json a.svg -> image/svg+xml a.wasm -> application/wasm a.csv -> text/csv a.md -> text/markdown
查看线上 URL 实际返回的 Content-Type
curl -sI https://example.com | grep -i '^content-type'接口返回 JSON 却被浏览器追问是否保存时，先用这条命令确认响应头，再回头改服务端或网关的映射。
输出
Content-Type: text/html; charset=utf-8
起一个本地服务，观察不同路径返回的类型与状态
node -e "
const http = require('http');
const srv = http.createServer((q, s) => {
if (q.url === '/sse') { s.writeHead(200, { 'Content-Type': 'text/event-stream' }); return s.end('data: hi\n\n'); }
if (q.url === '/dl') { s.writeHead(200, { 'Content-Type': 'application/octet-stream' }); return s.end('x'); }
s.writeHead(404, { 'Content-Type': 'text/plain' }); s.end('nope');
});
srv.listen(8931, async () => {
for (const p of ['/x', '/sse', '/dl']) {
const r = await fetch('http://127.0.0.1:8931' + p);
console.log(p, r.status, r.headers.get('content-type'));
}
srv.close();
});
"同一个服务里，octet-stream 让浏览器下载、event-stream 保持连接、text/plain 内联渲染——差别全在 Content-Type 这一个头。
输出
/x 404 text/plain /sse 200 text/event-stream /dl 200 application/octet-stream
常见坑与注意事项
- 接口明明返回 JSON，浏览器却弹出「是否保存文件」——先查响应头，八成是 Content-Type 写错或缺失，而不是数据有问题。
- multipart/form-data 必须带 boundary 参数；手写请求体而漏掉它，服务端会报缺少 boundary 或解析不出任何字段。
- SVG 是可执行 XML：允许用户上传 .svg 而不做净化，等于把脚本注入的口子直接开到页面上。
- 新 Office 文档要用 vnd.openxmlformats-* 正式类型名，继续沿用旧的 msword / vnd.ms-excel 会让新版 Office 报「文件格式与扩展名不一致」。
- 字体加载优先写 font/woff2 并保留 woff 或 ttf 回退；只给老格式会让现代浏览器直接放弃加载而不报错。
提示
- Nginx 配置 MIME 类型在 /etc/nginx/mime.types 文件。
- 上传文件时 Content-Type 设为 multipart/form-data，浏览器会自动处理边界。
- JSON API 响应头应设为 application/json; charset=utf-8。
- octet-stream 会触发浏览器下载，用于未知类型或强制下载场景。
常见问题
text/javascript 和 application/javascript 到底该用哪个？
选 text/javascript。application/javascript 是历史遗留名，RFC 4329 已将其注册为 text/javascript 的过时别名；现代浏览器、CDN 与压缩工具链对 application/javascript 的处理各不相同，有的会拒绝渲染成脚本。唯一还能见到 application/javascript 的地方是老的 IE 时代代码，那些代码早已不值得迁就。
application/json 和带 charset 的 application/json; charset=utf-8 有区别吗？
几乎所有场景没有实质区别，但推荐显式写 charset=utf-8。JSON 的规范编码就是 UTF-8，charset 参数对 JSON 是冗余的；不过在 Content-Type 里显式声明能让 CDN、浏览器与调试工具一眼确认编码，也避免个别老客户端默认按本地编码猜测。真正必须带 charset 的是 text/* 系列，因为它们存在历史遗留的编码歧义。
文件上传的 Content-Type 为什么总是 multipart/form-data？
因为 multipart/form-data 不是「一个类型」，而是「一套分段格式」。请求体被 boundary 切成若干段，每段各有自己的 Content-Type（普通字段是 text/plain，文件字段是 filename 加类型），boundary 参数指定分隔符。它存在的唯一理由是同时承载二进制文件与普通字段；如果请求里没有文件，用 application/x-www-form-urlencoded 更简单，服务器也更容易解析。
SVG 明明是图片，为什么被标成 image/svg+xml 而不是 image/png 那样的单一类型？
因为 SVG 不是位图，而是 XML 文档。它带 +xml 后缀表示内容是 XML，同时以 image/ 作为顶层类型表示用途是图片。这个组合让浏览器既能当图片渲染（能进 <img>、能当 CSS background），又保留 XML 的可解析性（能读 DOM、注入脚本）。代价是它同时具备「能执行脚本」和「可被引用为图片」两个身份，因此上传时需要比 PNG 更严格的净化。
服务端的 application/octet-stream 和 application/x-www-form-urlencoded 分别在什么时候用？
application/octet-stream 是「我不知道这是什么」的兜底类型，用来触发浏览器下载而不是尝试渲染；它适合任意二进制流，也是本表里最安全的默认值。application/x-www-form-urlencoded 是 HTML 表单的默认提交格式，把键值对用 & 连接、值做百分号编码，适合纯文本字段的提交。两者的取舍点在于请求体是否包含二进制内容：有文件就必须 multipart，纯键值则 urlencoded 最省事。
由 巧匠 维护
公开更新于 2026年7月21日，内容持续校对官方文档。