副檔名會對應到一個MIME類型，讓伺服器、瀏覽器與電子郵件用戶端知道該如何處理接下來的位元組。字串image/png告訴瀏覽器要繪製像素，application/json告訴解析器要建立樹狀結構，font/woff2則告訴引擎要把內容視為Web Open Font Format容器來處理。MIME Type Lookup工具提供24組這類對應關係，並對照IANA媒體類型登錄庫與MDN的常見類型表進行交叉檢查，讓你可以依副檔名、格式家族或部分字串，找到已登錄的基本類型，並直接複製貼到Content-Type標頭、允許清單或測試夾具中。由於複製動作只會把基本類型放到剪貼簿上，你可以把結果貼進伺服器路由、JSON設定檔或curl指令中，而不會夾帶不相關的參數。每一筆資料都會把副檔名別名、登錄的媒體類型，以及淺顯易懂的格式標籤放在一起，讓你在送出之前就能確認即將送出的內容。
大多數在職開發者一次只需要用到少數幾組對應關係，但反覆用到的總是同一批：HTML、CSS、JavaScript、JSON、常見的影像格式、SVG，以及現代字型類型。就日常使用而言，一份精心整理的小型參考資料，會比一份龐雜的IANA登錄庫複本更好用，而且能提供一組穩定的數值供你貼進設定檔，不會因為標準組織每次登錄新的子類型就跟著變動。
依副檔名查詢MIME類型
當設定檔需要一個Content-Type數值、允許清單需要決定接受哪些類型，或測試夾具需要指定上傳項目該宣告什麼類型時，最快的做法就是直接查詢這份參考資料。MIME Type Lookup工具在你的瀏覽器中執行，因此不會上傳任何檔案，搜尋文字也不會離開頁面。
- 在搜尋欄位中輸入副檔名、格式名稱或媒體類型。輸入.json、輸入image這個家族名稱，或輸入像font/woff2這樣的完整數值，都能篩選出符合的資料列。
- 確認符合的說明文字與副檔名別名。淺顯易懂的標籤會告訴你這一列實際代表哪種格式，而別名欄則標示出共用同一個登錄類型的其他副檔名。
- 複製精確的基本媒體類型，並在使用前對照實際內容進行驗證。把複製的字串貼進你的標頭、允許清單或設定檔，然後確認部署後的回應或上傳處理程式，從頭到尾回報的都是同一個數值。
就第三個步驟而言，驗證並不是可有可無的。你的框架所提供的回應，可能因為中介軟體、代理伺服器改寫，或靜態檔案處理程式的緣故，而與你設定的數值不一致，因此唯一重要的檢查，是用戶端實際看到的內容。
常見副檔名對應MIME類型一覽
這份參考資料把幾種常見格式對照IANA登錄資訊固定下來，讓你不需要離開頁面就能複製已知正確的數值。以下八列資料取自工具鎖定的固定資料，並同時對齊IANA登錄庫與MDN的常見類型表。
| 副檔名 | 基本媒體類型 | 格式 |
|---|---|---|
| .html, .htm | text/html | 超文本標記語言 |
| .css | text/css | 階層式樣式表 |
| .js, .mjs | text/javascript | JavaScript模組或指令碼 |
| .json | application/json | JSON資料交換格式 |
| .png | image/png | 可攜式網路圖形格式 |
| .jpg, .jpeg | image/jpeg | 聯合圖像專家小組（JPEG）影像 |
| .svg | image/svg+xml | 可縮放向量圖形 |
| .woff2 | font/woff2 | 網頁開放字型格式2（Web Open Font Format） |
這八組對應關係涵蓋了日常網路流量的一大部分，而且每一個都是符合規範的伺服器應該送出的數值。如果你維護的是靜態網站、CDN設定或小型API，光靠這張表就能建立一份可用的mime.types檔案。
副檔名只是提示，不是證明
檔名副檔名與真正的內容類型並不是同一件事，把兩者當成同一件事，正是上傳流程中最常見的安全性與正確性錯誤來源之一。MIME Type Lookup工具明確地把application/octet-stream作為未知二進位資料的通用備援值，且不附帶任何虛構的副檔名，因為對於伺服器無法辨識的資料塊而言，唯一誠實的答案就是「這是一堆位元組，請視為不可信」。
這份參考資料記錄了幾種真實發生過的失敗模式。一個名為picture.png的檔案，可能包含非PNG的位元組；瀏覽器提供的File.type，也可能是空值、過時，或者只是根據作業系統的副檔名對應關係推導出來的。因此，安全的上傳處理必須檢查實際內容、強制執行大小與格式限制、使用經過妥善維護的安全解析器解碼、對儲存的物件重新命名、將其與執行環境隔離，並套用授權機制。這些步驟都不能靠信任副檔名或請求標頭來取代，而你在分頁中開著的mime查詢工具，同樣也適用這個原則。
實務上的原則是，把這個工具，以及依賴它的標頭與表單，都視為架在嚴格允許清單與內容偵測步驟之上的一層提示。查詢工具能幫你挑出正確的字串；至於位元組是否真的相符，則是你的程式碼該負責確認的事。
基本類型與參數之分：標頭裡該放什麼
已登錄的媒體類型，是由用斜線分隔的頂層類型與子類型組成的，而HTTP標頭可以在子類型之後附加參數。實際的標頭經常會像Content-Type: text/html; charset=utf-8，或Content-Type: multipart/form-data; boundary=----abc這樣，但這份參考資料刻意只列出已登錄的基本類型。複製動作只會把那個基本數值單獨放到剪貼簿上，是否要附加charset、boundary或其他任何參數，則由你依實際提供的格式自行決定。
這種區分很重要，因為參數跟類型一樣容易出錯。在application/json後面加上charset=utf-8並無妨，因為JSON本質上是文字；但把它加在image/png後面就毫無意義，只會顯得混亂。編碼格式、傳輸編碼、內容配置（content disposition）與壓縮方式，同樣是獨立於媒體類型之外的考量。路由與允許清單請使用基本類型，只有在格式與協定確實需要時，才加上參數。
當這24組對應關係還不夠用時
這個集合是刻意設限的。特定廠商的辦公室格式、multipart邊界的組成方式、電子郵件傳輸編碼、編碼參數，以及各種冷僻的已登錄子類型，都不在涵蓋範圍內；對於這24筆資料以外的內容，本頁會連結到IANA媒體類型登錄庫，以及MDN的常見媒體類型指南。如果你的專案用到表中沒有的格式，請點選連結前往IANA登錄庫確認已登錄的子類型，因為這份精選集合是刻意落後於完整登錄庫，以維持小巧與穩定。
有些副檔名也存在歷史或情境上的替代版本。在某些流程中，XML可能會以application/xml提供服務，而特定用途的XML格式則有專屬的+xml子類型，例如image/svg+xml或application/atom+xml。JavaScript在歷史上曾出現在好幾個舊有數值底下；目前的網頁規範與IANA登錄則採用text/javascript，也就是這張表所回報的數值。.gz檔案可能標示為已登錄的application/gzip，或某些平台採用的非標準值application/x-gzip，而這個工具呈現的是目前常見的其中一種對應關係，而不是假裝所有伺服器、登錄庫或歷史上的瀏覽器都意見一致。若協定合約必須與特定部署相符，請直接重新查核主要登錄庫。
為了在日常使用中保持可靠，請先在表中找到對應格式、確認內容位元組確實與之相符、複製已登錄的基本類型，再測試實際的回應或上傳路徑。請把未知內容視為不可信的二進位資料，並且優先採用明確的允許清單，而不是照單全收接受這張表裡的每一種類型，因為登錄資訊與實作準則，都可能各自獨立地持續演變，與任何精選參考資料脫節。
如果你還在評估選項，在Windows或Mac上找到正確的PowerPoint快捷鍵這篇文章有詳細說明。