搜尋常見副檔名及其 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 這類較新的格式，正是老舊伺服器配置中最常缺失的條目。