# JPG to WebP > 在瀏覽器內把 JPG 重新編成 WebP。實測只小了 9.7%，EXIF 與 ICC 色彩描述檔都會不見，方向標記直接烙進像素裡，從原檔輸出才拉得開差距，全程不必上傳。 - URL: https://bytescope.dev/zh-Hant/image-convert/jpg-to-webp/ - Locale: zh-Hant · Also: [en](https://bytescope.dev/en/image-convert/jpg-to-webp.md) · [ja](https://bytescope.dev/ja/image-convert/jpg-to-webp.md) - Runs: 檔案不會離開你的瀏覽器 — 全部在本機處理。 - Requires: Any modern browser (Chrome, Edge, Firefox, Safari), desktop and mobile. - Updated: 2026-09-08 ## What it does ### JPG 轉成 WebP 會失去什麼 以結構來說幾乎沒有：來源沒有 alpha 色版，也沒有多格影像，新容器根本沒東西可丟。真正流失的是元資料與世代。所有 EXIF 欄位都會消失——拍攝時間、相機與鏡頭、曝光參數、GPS 座標——嵌入的 ICC 色彩描述檔同樣不留，因為這是解碼成像素再重編，不是換個盒子裝。對手機拍的照片來說，這幾乎就是日後在相簿裡找得到它的全部線索；反過來說，這也正是公開分享前你會想清掉的東西。 方向是唯一表現不同的欄位，值得記住。解碼時要的是「應該被看到的樣子」，所以 EXIF 的 `Orientation` 標成要轉四分之一圈的照片，會在編碼前先把像素轉正。輸出因此在任何地方打開都是正的，即使標記本身已經不在。好處是不會有人拿到躺著的照片，代價是之後也不能靠改標記把它轉回去——旋轉已經變成畫面的一部分了。 真正的成本是這變成第二代有損壓縮。來源早就以 8 × 8 區塊為單位丟掉高頻細節，色彩也只存了一半解析度。新的編碼器分不出區塊接縫、振鈴光暈與真正的細節，於是它會花位元忠實重現上一個編碼器犯的錯，然後再量化一次。把品質調高只能限制這一輪的傷害，修不好上一輪的；打開無損則會把瑕疵完美保存下來並讓檔案大很多，在這條路線上幾乎沒人想要這種結果。 ### 實測時檔案大小怎麼變 2026-09-12 的腳本先把 1280 × 854 的素材以品質 85 編成 JPG，得到 351,967 位元組，再用 @jsquash/webp 以同樣的品質 85 編成 WebP，得到 317,848 位元組。只小了約 9.7%，遠低於一般引用的 25–35%。那個數字比的是兩種編碼器對同一份原始母檔的表現；這裡交給新編碼器的，是一張已經在相同品質下量化過的圖，聰明編碼器本來可以省下位元的細節早就不見了。從原檔輸出才拉得開差距，這也是整批轉舊圖庫常令人失望的原因。 ### 什麼時候不該把 JPG 轉成 WebP 不要整批轉照片庫。照實測來看，你得替每一個檔案多付一整代有損壓縮，換來不到一成的位元組，還順手清掉整個圖庫賴以排序的日期與地點。原檔還在的話，請從原檔輸出，那才是這個格式真正發威的地方。要寄電子報、要送印，或要丟進副檔名清單寫死的上傳欄位的檔案也別轉。可能需要保留 EXIF 的圖同樣別轉，例如存證照片，或任何要追授權與來源的素材。為了某個你能自己改標記的頁面轉個幾張，或想看看主視覺縮到多小還能看，那都是很合理的用法。 轉換完全在你的瀏覽器內進行 — 不上傳、不排隊、無浮水印。想放幾個檔案都行，可逐一下載，也能打包成 zip。 ## Limits 以結構來說幾乎沒有：來源沒有 alpha 色版，也沒有多格影像，新容器根本沒東西可丟。真正流失的是元資料與世代。所有 EXIF 欄位都會消失——拍攝時間、相機與鏡頭、曝光參數、GPS 座標——嵌入的 ICC 色彩描述檔同樣不留，因為這是解碼成像素再重編，不是換個盒子裝。對手機拍的照片來說，這幾乎就是日後在相簿裡找得到它的全部線索；反過來說，這也正是公開分享前你會想清掉的東西。 方向是唯一表現不同的欄位，值得記住。解碼時要的是「應該被看到的樣子」，所以 EXIF 的 `Orientation` 標成要轉四分之一圈的照片，會在編碼前先把像素轉正。輸出因此在任何地方打開都是正的，即使標記本身已經不在。好處是不會有人拿到躺著的照片，代價是之後也不能靠改標記把它轉回去——旋轉已經變成畫面的一部分了。 真正的成本是這變成第二代有損壓縮。來源早就以 8 × 8 區塊為單位丟掉高頻細節，色彩也只存了一半解析度。新的編碼器分不出區塊接縫、振鈴光暈與真正的細節，於是它會花位元忠實重現上一個編碼器犯的錯，然後再量化一次。把品質調高只能限制這一輪的傷害，修不好上一輪的；打開無損則會把瑕疵完美保存下來並讓檔案大很多，在這條路線上幾乎沒人想要這種結果。 ## FAQ ### 為什麼 JPG 轉成 WebP 只小了一成左右？ 因為輸入在同樣的品質下已經壓過一次，新編碼器沒剩多少可省。常看到的 25–35% 是拿兩種格式跟未壓縮的原檔比。想要完整的效益，請從母檔輸出，而不是再疊一次有損壓縮。 ### JPG 轉 WebP 會保留拍攝日期、GPS 與方向標記嗎？ 日期、GPS、相機欄位與色彩描述檔都會被丟掉，因為檔案是用解碼後的像素重建的。方向在效果上是例外：旋轉會在編碼前先套用到像素，所以畫面仍然是正的，但標記本身沒有留下來。 ### 整個照片圖庫都該這樣轉嗎？ 很少值得。你會替每個檔案多加一代有損壓縮，丟掉圖庫用來排序的元資料，而實測樣本只換到不到一成。挑特定頁面要用的圖來轉很划算，整批就地換掉通常不划算。 ### 我的圖片會被上傳到任何地方嗎？ 不會。轉換在你的瀏覽器內使用 canvas API 和 Web Worker 完成 — 檔案不會離開你的裝置。沒有上傳步驟、不用排隊，檔案大小也只受限於你電腦的記憶體。 ### 轉換後的圖片會保留 EXIF 中繼資料嗎？ 不會 — 而這正是特色之一。透過 canvas 重新編碼會移除所有中繼資料：GPS 位置、相機型號、時間戳記和色彩描述檔。輸出只包含像素，而這通常正是你公開分享圖片前想要的結果。 ### 可以一次轉換很多張圖片嗎？ 可以。拖放或貼上任意數量的檔案；每個檔案都會在背景轉換，各自有進度顯示和下載按鈕，也可以把全部內容打包成 .zip 一次下載。 ### 轉檔會讓畫質變差嗎？ 看你選的目標格式。不管來源和目標是哪兩種格式，轉換器一律先解碼成原始像素再重新編碼，中繼資料也是這樣被移除的。目標是無損格式（PNG，以及在 256 色限制內的 GIF）時，像素和解碼出來的完全一樣；目標是 JPEG、WebP 或 AVIF 時，則由品質滑桿控制取捨，而且來源本來就是有損檔的話，會再多疊一層損失。