正在載入您的檔案…

把 JPG 轉成 WebP,幾秒得到更小的檔案

把任何 JPEG 變成更輕的 WebP,檔案縮小 25% 到 34%,一張圖在瀏覽器裡處理,多張則一起在我們的伺服器上處理。

或將圖片拖放至此

預覽僅在您的裝置上進行,拍攝前不會記錄任何內容。

JPG 轉 WebP 怎麼做

JPG 轉 WebP 怎麼做

把一張 JPEG 拖進上傳區,或點一下從裝置選檔。檔案一進來,轉換立刻開始。沒有「轉換」按鈕要找,也沒有佇列要等。瀏覽器完全在你自己的硬體上把照片重新存成 WebP。結果出來時,狀態列會把原始大小和新的大小並排放,省下多少一目了然。點「下載」把 WebP 留下,它沿用相同的主檔名,只換上新的副檔名。要再處理一張,直接把它疊到上一張上面就好。頁面不會重新載入,一般手機照片不到一秒就完成。

為什麼 WebP 會比 JPG 小

為什麼 WebP 會比 JPG 小

兩種格式都會丟掉資料來壓縮照片,但在任一品質下 WebP 做得更聰明。Google 把對 JPEG 的典型增益定在 25% 到 34%,而資訊量大的真實照片常常更高。我們實測的結果也支持這點。一張 1024×768 的 JPEG 掉到 ,一張 3840×2160 的 照片降到 。圖片位元組越少,Largest Contentful Paint 就越快,這個載入指標被 Google 納入排名系統。WebP 還免授權費,這正是每家大型 CDN 預設供應它、而每個現代瀏覽器都能直接讀取它、不用外掛也不用下載的原因。

什麼時候 WebP 勝過 JPG,什麼時候不

什麼時候 WebP 勝過 JPG,什麼時候不

凡是要放到你自己經營的網頁上,就選 WebP:主視覺、商品照、部落格配圖、相簿縮圖,以及你自家網域供應的預覽卡片。每個現代瀏覽器都讀得了,這在 2026 年涵蓋超過 97% 的流量,Safari 從第 14 版起也算在內。當檔案得送到仍預期 JPEG 的地方時就留在 JPG,例如電子郵件附件、印刷工作、較舊的相片編輯器、市集的上傳表單,或是會悄悄把 WebP 再壓回 JPEG 的平台。決定權在目的地,不在起點。如果你掌控圖片供應的地方、而觀眾用的是近期瀏覽器,那麼幾乎在每種情況下 WebP 都是更強的選擇。

品質與第二次有損處理

品質與第二次有損處理

你的 JPEG 本來就是有損的,所以把它變成 WebP 等於在第一次之上再疊一次有損處理。理論上額外的雜訊可能累積。但實際上,在這裡採用的近乎無損設定下,照片在任何正常觀看距離都跟原圖看起來一樣。想要最乾淨的輸出,總是從你手上最好的 JPEG 開始,用相機直出的原檔,而不是已經經過聊天軟體或 CDN 壓縮的副本。每經一手都會多損一點。這個版本只供應一個校準過的品質等級、沒有滑桿,讓輸出可預期,也省去把不需要再壓的照片過度壓縮的誘惑。

你的檔案在哪裡處理

你的檔案在哪裡處理

轉換一張圖直接發生在你的瀏覽器裡,在你自己的機器上,沒有任何上傳。一次轉換多張時,檔案會送到我們的伺服器一起完成,下載連結約 2 小時後刪除。無論哪種方式結果都歸你,不會被記錄或研究。 兩種情況均無長期儲存,也不收集任何資料。你的檔案受到保護。

2026 年的 WebP 瀏覽器支援

2026 年的 WebP 瀏覽器支援

今天全球超過 97% 的瀏覽器讀得了 WebP。Chrome 從 2012 年的第 17 版起就能解碼它,Firefox 從第 65 版起,Safari 從 iOS 上的第 14 版以及 macOS Ventura 上的第 16 版起。Edge 和 Opera 都原生支援。真正還沒跟上的只有 Internet Explorer 11 和 Safari 13,而它們的占比如今微乎其微。對一般網頁供應,你可以放心供應 WebP。如果你真的得照顧到很舊的瀏覽器,就把 WebP 和一張 JPG 後備放進 HTML 的 picture 元素裡,讓每個瀏覽器各取所能讀的。至於電子郵件、共享磁碟和印刷,JPG 仍是更穩的選擇。

運作方式

  1. 放入或選取你的 JPG

    點一下上傳區,或從桌面把 JPEG 拖進去。檔案一落地,轉換就自己開始,沒有按鈕要按。

  2. 讓編碼跑完

    你的瀏覽器在自己的記憶體裡把一張照片重新編碼成 WebP,沒有任何要上傳的東西。一張普通手機照片遠不到一秒就完成。

  3. 看大小對照

    WebP 準備好時,狀態列會把舊的 JPEG 大小和新的 WebP 大小並排顯示,讓你確認到底省了多少。

  4. 下載 WebP

    點「下載」存下結果。檔案保留原名,副檔名自動換成.webp,什麼都不用改名。

常見問題

為什麼要把 JPG 轉成 WebP?

在同樣的視覺品質下,WebP 的檔案比 JPEG 小,這會加快頁面載入並拉高你的 Core Web Vitals。Google 為 WebP 公布的數字是比 JPEG 輕 25% 到 34%,真實照片常常更好。如果你在替網站管理圖片,從 JPEG 換到 WebP 能省下頻寬費用,也可能直接改善你的 Largest Contentful Paint,而這會回饋到搜尋排名上。

這個轉換是無損的嗎?

不是。WebP 和 JPEG 都是有損的,所以從一個轉到另一個會多加一輪有損壓縮。在這裡採用的近乎無損品質下,照片在正常觀看距離看不出差別。如果你真的需要無損結果,就改轉成 PNG。任何承諾無損 JPG 轉 WebP 路徑的工具都是錯的,因為 WebP 無損是另一種模式,是為 PNG 那類來源美術而設,不是給照片用的。

WebP 檔案比 JPEG 小多少?

在我們的測試中,一張 1024×768 的 JPEG 變成 ,一張 3840×2160 的 照片落在 。Google 公布的數字是在同等品質下比 JPEG 輕 25% 到 34%。已經被重壓過的很小的圖,例如 以下的縮圖,省下的通常較少,因為它本來就已經貼近編碼的下限了。

WebP 支援透明度嗎?

支援。WebP 帶有完整的 alpha 通道,而 JPEG 沒有,這也是它適合網頁圖形的原因之一。不過對 JPG 轉 WebP 來說,並沒有透明度需要保留,因為來源 JPEG 本來就是完全不透明的。如果你的圖片一開始是帶透明度的 PNG,又想在 WebP 裡保留那份透明度,請直接從那張 PNG 轉,而不是從中間那張已經被填平的 JPEG。

我的圖片會被上傳到伺服器嗎?

這取決於數量。轉換一張圖完全在你的瀏覽器裡執行,沒有向外的圖片請求。一次轉換多張會把它們送到我們的伺服器一起處理,下載連結約 2 小時後刪除。兩種情況下都沒有長期儲存,也沒有資料收集。

我可以一次把好幾張 JPG 轉成 WebP 嗎?

可以。放入兩張或更多 JPEG,它們會一起轉換,再作為一個下載返回。為此檔案會送到我們的伺服器,把 WebP 結果打成一個壓縮檔,給你一個約 2 小時後刪除的連結。單張 JPEG 仍然直接在你的瀏覽器裡轉換,沒有任何上傳。

詳細資訊

團隊關於工藝、格式以及一個好結果背後小決定的筆記。

單張圖如何在瀏覽器裡轉換,以及多張時有何不同
當你把一張 JPEG 拖到頁面上,瀏覽器把檔案讀進記憶體,用內建的 JPEG 讀取器把壓縮資料解碼回原始像素,把這些像素畫到一個螢幕外的表面上,再請求平台把它們寫成 WebP。每一步都在瀏覽器裡、在你自己的硬體上完成,所以沒有位元組穿過網路。在我們的執行中,1024 乘 768 的 JPEG 約需 54 毫秒,3840 乘 2160 的 照片約需 550 毫秒。一次轉換多張圖時,工作改在我們的伺服器上完成,把它們一起編碼並返回一個下載,其連結約 2 小時後刪除。
EXIF 和中繼資料會怎麼樣
JPEG 檔案可能扛著真正的中繼資料。EXIF 記下相機型號、GPS 座標、快門速度和方向。IPTC 欄位裝著版權與圖說。XMP 封包追蹤編輯歷程,ICC 描述檔則涵蓋色彩管理的工作。這裡的轉換一個都不保留。輸出的 WebP 是一個只裝看得見像素的乾淨檔案。對任何透過瀏覽器繪製的圖片工具來說,這是常態,Chromium、Firefox 和 WebKit 都一樣。對大多數網頁發布而言,丟掉中繼資料是好事:它省下幾個位元組,也避免 GPS 或個人資料外洩到一張公開的圖片裡。如果你需要保留某個特定欄位,方向通常是那一個,就先把照片轉正,或在轉換前用一個懂中繼資料的編輯器處理。別把這個工具用在原始中繼資料必須完整存活的典藏工作上。
WebP 對 JPEG:壓縮的差別在哪
JPEG 把影像切成 8×8 的區塊,跑離散餘弦轉換把空間細節變成頻率資料,再對較高的頻率量化得更狠。WebP 借用了 VP8 影片的一套預測機制:每個區塊都從已經解碼好的鄰居去猜,只有剩下的差值被存起來。在同樣的檔案大小下,這往往留下較少的方塊狀雜訊,尤其在平滑漸層和膚色上,那裡 JPEG 的網格容易浮現成看得見的馬賽克。在高品質照片上、q80 以上,肉眼很少抓得到差別,但大小優勢一直都在。在較低品質、q60 以下,WebP 的領先擴大,雜訊的性格也變了:WebP 化成較柔的模糊,JPEG 則露出它招牌的方塊。沒有哪一個在每張圖上都贏。像枝葉這種重紋理的主體,兩種格式有時壓出來差不多。
Core Web Vitals 與選擇 WebP 的理由
Largest Contentful Paint,也就是 LCP,量的是視窗內最大的可見元素多快完成載入。在大多數行銷頁上,那個元素就是一張主視覺照片。Google 已確認 Core Web Vitals 在搜尋中是排名因素。當主視覺是一張 的 JPEG 時,在中階的行動連線上它可能把 LCP 推過 2.5 秒的門檻。把同一張照片轉成大約 的 WebP,LCP 就可能在頁面其他都不動的情況下滑回綠區。這 25% 到 34% 的節省會在頁面上每一張圖上累積。一個帶六張、合計 JPEG 的頁面,改用 WebP 後可以甩掉 300 到 ,這會直接加快慢速連線上的首次有意義繪製。支援內容協商的 CDN 會自己把 WebP 交給相容的瀏覽器,所以原檔一旦存在,每張圖就不再有額外的雜務。
2026 年 WebP 的瀏覽器支援與缺口
到了 2026 年,WebP 從 Chrome 第 17 版、Firefox 第 65 版、Edge 第 18 版、Opera 第 11.10 版,以及 iOS 14 和 macOS Big Sur 上的 Safari 第 14 版起就能讀。根據 caniuse.com,WebP 解碼的全球綜合覆蓋率超過瀏覽器流量的 97%。剩下的一小撮主要是 Internet Explorer 11、macOS Catalina 上的 Safari 13,以及一條很舊的 Android 瀏覽器長尾。對大多數公開專案來說,對所有人供應 WebP 都很安全。當你需要全面覆蓋時,HTML 的 picture 元素讓你在同一個標籤裡列出一個 WebP 來源和一個 JPEG 後備,瀏覽器會挑它讀得了的第一個格式。帶影像最佳化的 CDN 會從瀏覽器送出的 Accept 標頭自動協商格式,所以透過它們供應時不必逐一手動測試每個瀏覽器。
什麼時候不該用 WebP
對供應給現代瀏覽器的網頁來說 WebP 是對的,但在幾個常見場合它是錯的。印刷工作需要 CMYK 色彩,而 WebP 不帶這個,所以 JPEG 和 TIFF 在印刷上仍是標準。電子郵件用戶端表現參差:Gmail 和 Apple Mail 會繪製 WebP,但 Windows 上的 Outlook 不會。檔案分享和市集也各有不同。Google Drive、Dropbox 和 GitHub 都能好好顯示 WebP,但許多社群平台、圖庫和電商系統會在內部把進來的圖片再壓回 JPEG,這讓那一步 WebP 變得徒勞。編輯器的支援也還參差:Lightroom、Capture One 和 Affinity Photo 能開 WebP,但不少外掛和匯出預設仍預設成 JPEG。對任何會讓圖片經過你無法掌控的第三方系統的流程,請保留一份 JPEG 母檔,只在最後的交付這一層才轉成 WebP。