轉檔為
調整尺寸
✓ 輸出檔案已完全移除 EXIF、GPS 等所有元資料。
拖放圖片至此處
或點擊瀏覽 — PNG, JPEG, WebP, GIF, HEIC, AVIF, SVG — 亦可在頁面任意處貼上圖片（Ctrl+V）
拿 WebP 的壓縮效率去換一個舊軟體、印刷廠與上傳欄位都一定收的 JPG。
檔案不會離開你的瀏覽器 — 全部在本機處理。
✓ 輸出檔案已完全移除 EXIF、GPS 等所有元資料。
拖放圖片至此處
或點擊瀏覽 — PNG, JPEG, WebP, GIF, HEIC, AVIF, SVG — 亦可在頁面任意處貼上圖片（Ctrl+V）
先沒的是透明度。目標格式沒有 alpha 色版，所以貼圖、logo 或去背的商品照都會和上方設定選定的背景色合成，工具一找到要鋪平的 alpha 色版就會提出警告。成品是一塊方形：主體現在坐在白底上，或你挑的那個顏色上，而且之後無法從結果反推回去背版本。半透明像素——陰影的柔邊、淡淡的浮水印——是被混進那個顏色，不是被切掉，所以它在那一個底色上看起來正確，換到任何別的底色就會出錯。
接著沒的是動畫。多格來源會依影格數被偵測出來，在這個目標下工具只留第一格、關掉解碼器，並警告只轉了一格。間隔時間與循環次數在靜態格式裡沒有對應的東西。把目標改成 GIF 可以保住整段動畫，維持原格式當然也保得住。
然後才是慣例的代價：來源容器裡的 EXIF 與 ICCP 區塊不會複製過去，而且這是第二代有損壓縮。第一個編碼器已經量化過畫面，第二個又用不同的轉換與 4:2:0 色度取樣把解碼結果再量化一次，兩批瑕疵就這樣疊起來。由於這個來源格式常被拿來放 UI 素材，對象是平面圖形與文字的機會很高，而那正是新階段會添上原本沒有的振鈴的情況。
這一對正好是大家的直覺反過來的例子。2026-09-12 的腳本測了一張 1280 × 854、品質 85 的有損 WebP，319,834 位元組，再用同樣的品質 85 搭配 4:2:0 編成 JPG，得到 347,607 位元組。明明是同一張照片的第二代，輸出卻比輸入大了約 8.7%。所謂新格式比較有效率就是這個意思：在品質設定對齊的前提下，它需要的位元組就是比較少。JPG 那個數字來自 Node 裡的 sharp，你的瀏覽器走 canvas，實際值會有一點出入，但結論不動——這是為了相容性做的決定，不是為了縮小檔案。
別為了省空間而轉，實測顯示通常是反過來多花。依賴透明度的東西也別轉，例如圖示、徽章，或必須擺在彩色頁面上的商品圖——PNG 留得住 alpha 色版，而且這頁就選得到。想繼續動的動畫同樣別轉。把它當成網頁的例行步驟也沒有意義，現行瀏覽器全都看得懂原格式。真正該用它的時機，是有某個特定軟體卡住了你：較舊的影像編輯器或辦公套裝軟體、印刷廠或沖印店的上傳頁、老舊的 CMS、只認一種副檔名的相機或電子書閱讀器，又或者收件欄位上只寫了 .jpg 的表單。
轉換完全在你的瀏覽器內進行 — 不上傳、不排隊、無浮水印。想放幾個檔案都行，可逐一下載，也能打包成 zip。
通常不會。在 1280 × 854、品質同為 85 的實測裡，319,834 位元組變成 347,607 位元組，大了約 8.7%，而且還多一代有損壓縮。請為了相容特定軟體而轉，不要為了省頻寬。
透明區域會被設定裡的背景色填滿，沒改就是白色，並且會顯示警告。去背的結果無法從成品救回來，所以請挑圖片實際要擺的底色，或者改成轉 PNG。
通常是較舊的桌面影像編輯器與辦公套裝軟體、部分印刷與沖印的上傳系統、老舊的出版系統、少數相機與電子書閱讀器，以及收件副檔名清單比新格式還早訂下的表單。現行網頁環境兩種都打得開。
不會。轉換在你的瀏覽器內使用 canvas API 和 Web Worker 完成 — 檔案不會離開你的裝置。沒有上傳步驟、不用排隊，檔案大小也只受限於你電腦的記憶體。
不會 — 而這正是特色之一。透過 canvas 重新編碼會移除所有中繼資料：GPS 位置、相機型號、時間戳記和色彩描述檔。輸出只包含像素，而這通常正是你公開分享圖片前想要的結果。
可以。拖放或貼上任意數量的檔案；每個檔案都會在背景轉換，各自有進度顯示和下載按鈕，也可以把全部內容打包成 .zip 一次下載。
看你選的目標格式。不管來源和目標是哪兩種格式，轉換器一律先解碼成原始像素再重新編碼，中繼資料也是這樣被移除的。目標是無損格式（PNG，以及在 256 色限制內的 GIF）時，像素和解碼出來的完全一樣；目標是 JPEG、WebP 或 AVIF 時，則由品質滑桿控制取捨，而且來源本來就是有損檔的話，會再多疊一層損失。