Chrome 把圖片存成 .webp，是因為網站發來的就是它。你右鍵「另存圖片」時，Chrome 不做任何轉換——它把伺服器交付的位元組原樣寫入磁碟，而伺服器交付的是 WebP。不存在什麼隱藏很深的 Chrome 設定在搗鬼，所以你也找不到能關掉它的開關。最快的解法是存下來再轉換：我們的 WebP 轉 JPG 工具在瀏覽器裡運作，不上傳任何東西，存下來的 WebP 幾秒鐘就能變成正常的 JPG。想弄明白為什麼會變成這樣，或者想從源頭掐斷，繼續往下看。
Chrome 為什麼存 WebP：內容協商
瀏覽器每次請求圖片，都會附上一個 Accept 標頭，列出自己能解碼的格式。現代 Chrome 發的是類似 image/avif,image/webp,image/png,... 的東西——一封公開邀請函。伺服器看著這份清單，發現 WebP 受歡迎，就發 WebP，因為這是它被允許傳送的最小檔案。網站是故意這麼做的：WebP 能把圖片流量砍掉四分之一甚至更多（WebP 的誕生解釋了 Google 當初為什麼造它）。
同一支舞的老版本發的是 JPEG，因為那是瀏覽器當年宣告的全部。「另存圖片」沒有任何變化——這個選單項目歷來都是收到什麼存什麼。變的是收到的東西。而且這個機制已經在重演：Chrome 也宣告了 AVIF 支援，所以有些網站上存下來的檔案現在是 .avif——更新、更小，在瀏覽器之外的支援比 WebP 還差。
你可以親眼看它發生。開啟 DevTools（F12），切到 Network 分頁，重新整理頁面，點開圖片請求，看回應標頭。你會看到 content-type: image/webp。這個檔案在抵達你的下載資料夾之前很久，就已經是 WebP 了。
解法一：先存，再轉（可靠的那個）
存下 WebP，拖進 WebP 轉 JPG 工具，下載 JPG。整個循環幾秒鐘，對任何網站無例外地有效，而且——因為轉換在本機進行——你的檔案永遠不會經過別人的伺服器。攢了一整個資料夾的 WebP？一次全拖進去，結果打包成一個 ZIP 下載。完整步驟見 如何將 WebP 轉成 JPG。
如果圖片帶透明背景且你想保留，改用 WebP 轉 PNG 工具——JPG 會把透明度壓到白底上。
這是能跟著檔案走的解法：JPG 在你轉寄的任何人那裡都能開啟，這一點比聽起來更重要——WebP 檔案為什麼打不開是最常見的後續問題。
解法二：改網址（部分 CDN 有效）
很多圖片 CDN 按網址決定格式。在新分頁開啟圖片，如果網址以 .webp 結尾，試試改成 .jpg 或 .png 再重新整理。有些 CDN——尤其是做即時轉換的——會愉快地重新編碼，按你要的格式交付；還有一些接受 ?format=jpg 這類查詢參數。另一些則直接回 404，因為 WebP 檔案是唯一存在的版本。
花三秒鐘試一下是值得的。把工作流程建立在它上面則不值得。
解法三：讓 Chrome 不再請求 WebP（越來越脆弱）
既然伺服器跟著 Accept 標頭走，理論上可以讓 Chrome 不再宣告 WebP 支援。實際上路子已經變窄了。像「Save image as PNG」這類擴充功能走的是更友善的路線：攔截下載並自動轉成 PNG，檔案落碟時已經是轉好的。改寫 Accept 標頭的擴充功能也存在，但有些網站完全跳過協商，寫死回傳 .webp 網址——什麼標頭技巧都改變不了這一點。而且凡是碰請求標頭的東西，都會在 Chrome 更新擴充功能規則時悄無聲息地壞掉。
如果走這條路，先在你在意的那個具體網站上測過，再信任它。
解法四：截圖（最後手段）
是的，截圖完全繞開了格式問題。它也丟掉了原始解析度、所有內嵌中繼資料和一切透明度，並且捕獲的是頁面為了顯示而做過的壓縮和縮放。收個梗圖，可以。要複用的產品圖，同樣的十秒鐘還是花在解法一上更值——轉換出來的檔案是真正的影像，而不是影像的照片。
這一切存在的更深層原因，是 WebP 對網站確實更好，所以 WebP 檔案的供應只會越來越多——同一個支援缺口也是老表單拒收 WebP 上傳的原因。在桌面世界的其他部分追上來之前，把轉換器放在離你一個分頁的地方：存下圖，拖進去，然後繼續過你的日子。