如何在 Windows 上離線將 JPG 轉換為 WebP

大型相片可能在頁面其他設計尚未有機會發揮作用前，就已讓網頁顯得緩慢。將 JPG 轉換為 WebP 可以減少訪客下載的圖片位元組數，但真正有用的問題不在於 WebP 是否現代，而在於您產生的 WebP 是否更小、外觀是否仍可接受，以及網站是否正確傳送它。

在 Windows 11 上使用 LocalFlux，加入一個或多個 JPG 檔案、選擇 WebP，即可完成轉換，而不必將圖片傳送至線上服務。 開啟快速見效，選擇為網站準備。

介面截圖於2026年10月使用依據已記錄的 LocalFlux 1.0.10.0 發佈原始碼重新建置的版本拍攝。下方歷史測量值與下載資料仍保留原始測試範圍。截圖記錄： 1

經測試的網站圖片批次已在本機完成。LocalFlux 顯示，三個 WebP 檔案分別比其 JPG 輸入檔小 66%、67% 和 75%。這些測量結果只描述這組測試素材，並非對 WebP 的普遍保證。

最適合：用於登陸頁面、文章圖片、產品頁面、作品集，以及其他重視下載大小的網頁發佈工作流程中的 JPG 相片。

保留 JPG 原始檔：此 WebP 流程會再進行一次有損編碼。它無法還原已因 JPG 壓縮而移除的細節，而原始檔仍是較安全的編輯版本和後備版本。

2026 年 10 月 13 日複查：重新建置的 1.0.10.0 使用網站設定產生的全部 30 個輸出，皆與歷史網站 WebP 的雜湊一致。下表和直接轉換的下載檔仍是 1.0.7 的比較結果；直接轉換輸出經過解碼與重新測量，並未重新產生。三張圖片皆保持原尺寸。存在 EXIF 並不代表每個欄位皆已保留。 檔案驗證

簡短版步驟

1. 在 Windows 11 上開啟 LocalFlux。
2. 加入一個或多個 .jpg 或 .jpeg 檔案。
3. 保持選取轉換，並選擇WebP 作為輸出格式。
4. 開啟快速見效，選擇為網站準備。
5. 執行大型批次前，確認調整大小與品質設定。
6. 選取轉換。
7. 開啟新的 WebP 檔案、將細節豐富的區域與 JPG 比較，並測量實際位元組數。
8. 發佈 WebP 時，明確指定尺寸，並在相容性需求有需要時提供 JPG 後備版本。

從 Microsoft Store 取得 LocalFlux，或在開始前查看目前支援的格式與轉換路徑。

為什麼將 JPG 轉為 WebP 能改善網站

圖片要求會消耗頻寬，並與頁面的其他部分競爭。較少的位元組可以縮短傳輸時間，尤其是在速度較慢的手機或網路上。但這不代表更改副檔名就會自動改善效能：編碼結果、顯示尺寸、快取、回應式版本、要求優先順序，以及圖片在頁面上的位置，全都會產生影響。

Google 的圖片格式指南建議在 WebP 或 AVIF 等現代格式能提供適當的品質與大小結果時使用它們，同時在需要時保留較舊格式的途徑。Google 搜尋的圖片 SEO 指南同樣強調高品質圖片和速度，而不是把某一種格式視為排名捷徑。

JPG 和有損 WebP 都是相片內容的傳送格式。WebP 的實際機會在於，以可接受的視覺品質製作較小的傳送版本，而不是讓低品質 JPG 重新變得銳利。一旦 JPG 捨棄了精細紋理，或在邊緣周圍產生振鈴，轉碼就只能對剩餘的像素進行編碼。

此外，也應區分三項經常混為一談的工作：

工作	相關操作
變更瀏覽器傳送格式	將 JPG 轉換為 WebP
縮減過大的像素尺寸	調整為版面實際顯示的最大尺寸
移除位置、裝置、作者或日期中繼資料	使用支援的中繼資料移除工作流程，並驗證輸出版本

為網站準備範本會以保守方式結合前兩項工作，但不會啟用安全共享，也不保證達到特定位元組數。

本次測試使用的檔案

本逐步說明使用 C:\tmp\LocalFluxJpgToWebPBlog 下三個已取得使用權的 JPG：

• 一張 1440 × 960 的山景相片；
• 一張 1320 × 940 的 LocalFlux 介面螢幕截圖；以及
• 一張 1920 × 1080 的 LocalFlux 宣傳圖片。

相片用於測試自然紋理和漸層。介面擷取畫面用於測試小型文字和銳利邊緣，因為這些區域較容易看出第二次有損編碼的影響。宣傳圖片用於測試大面積純色區域和細微漸層。三張圖片全都不透明，因此本文不會重複 PNG 轉 WebP 指南中以透明度和圖形為重點的建議。

輸入檔涵蓋一張相片、具有銳利 UI 內容的圖片，以及一張網站風格的寬幅主視覺。使用中性的工作路徑和由儲存庫控管的媒體，可避免暴露個人 Windows 帳戶或客戶資產。

歷史比較圖：英文介面是測試圖片本身的內容，並非目前操作步驟。其中「KB」數值實際使用二進位單位（KiB）。

步驟 1：加入 JPG 檔案

將 JPG 檔案拖曳至 LocalFlux，或選取新增檔案。轉換前，請確認佇列中每一列都顯示JPG → WebP。一個批次會使用同一個輸出選項和同一組視覺設定，因此若檔案需要不同的傳送尺寸或品質等級，請分批執行。

WebP 只需為整個批次選取一次。LocalFlux 會在來源檔旁寫入新版本，而不會取代 JPG 檔案。

處理不熟悉的圖片庫時，請先使用具代表性的子集，而不是一次處理整個封存庫。加入一張細節豐富的相片；若素材集包含人像，則加入一張臉部相片；另加入漸層，以及帶有文字或標誌的圖片。適合樹葉的品質設定，對文字來說可能過於柔和。

步驟 2：選擇直接轉換或網站範本

有兩個實用的起點。

直接轉換會將格式變更為 WebP，同時維持原始尺寸，並採用編碼器的預設品質行為。這可單獨檢視格式變更的影響，並提供實用的基準。

開啟快速見效，選擇為網站準備。重新建置的 1.0.10.0 會套用以下設定：

• 輸出：WebP；
• 品質：82%；
• 調整大小規則：配合 1920 像素的長邊範圍；
• 長寬比：鎖定；
• 放大：永不；以及
• 中繼資料移除：關閉。

選定結果顯示在選項面板中。安全共享處於關閉狀態，中繼資料會保留。

1920 像素規則是上限，不是要求將所有圖片拉伸至 1920 像素的指令。三個測試檔案都未超過此上限，而 1920 × 1080 的主視覺本來就正好符合上限。因此，三個網站範本輸出檔全都保留了 JPG 尺寸。相較於直接轉換，它們額外節省的大小來自品質設定，而非調整大小。

步驟 3：檢查實際生效的選項

開啟選項並展開高階調整。請確認各項數值，不要假設同一個範本名稱在未來每個版本中永遠代表相同的實作。

摘要顯示 WebP、最大 1920 × 1920 和品質 82%。網頁預設保持長寬比且不會放大。在面板內捲動即可檢查其他設定。

品質並非跨格式通用的尺度。某個 WebP 編碼器中的 82，不保證與另一項工具中的品質 82 相符，也不保證特定位元組數。請將它視為此工作流程中可重現的起點。應比較實際結果，而不是憑傳聞選擇數值。

如果您的版面只會以 800 像素寬顯示圖片，1920 像素的檔案可能仍然過大。請調整為實際需要的最大呈現尺寸，或為多種版面寬度建立回應式版本。反之，也不要只為了在檔案大小比較中勝出，就將來源檔縮小到低於高密度顯示所需的尺寸。

步驟 4：轉換並檢查輸出版本

選取轉換 3 個檔案。LocalFlux 會建立另行命名的 .webp 檔案，並將 JPG 保留在原處。完成後，請在瀏覽器中以 100% 縮放比例檢查輸出。仔細查看：

• 頭髮、樹葉、布料及其他精細紋理；
• 小型文字和單像素介面線條；
• 高對比邊緣周圍的光暈或振鈴；
• 天空和深色漸層中的色帶；
• 色彩和方向；以及
• 寫入的確切尺寸與位元組數。

不要只根據縮圖總覽來判斷。以下顯示尺寸中的成對圖片看起來很接近，但在原始比例下，由於網站 WebP 是第二代有損版本，在最考驗品質的精細細節和介面區域中會明顯稍微柔和。這項取捨對傳送用途而言可能合理，但 JPG 應繼續作為來源檔或後備版本。

本次測試中的三個網站 WebP 全都保留原有尺寸，且檔案明顯更小。此比較並未聲稱像素完全相同或屬於無損轉換。

測量結果

直接轉換與網站範本執行使用相同的三個來源檔，以及相同的已封裝 LocalFlux 1.0.7 版本。

測試素材	JPG 輸入	直接 WebP	直接轉換變化	網站 WebP	網站轉換變化	尺寸
山景相片	274,913 位元組	169,980 位元組	小 38.2%	92,448 位元組	小 66.4%	1440 × 960
LocalFlux UI	126,755 位元組	64,626 位元組	小 49.0%	42,334 位元組	小 66.6%	1320 × 940
LocalFlux 主視覺圖片	67,861 位元組	28,880 位元組	小 57.4%	17,216 位元組	小 74.6%	1920 × 1080
總計	469,529 位元組	263,486 位元組	小 43.9%	151,998 位元組	小 67.6%	不適用

交付內容包括用於這些測量的確切山景 JPG、直接轉換的山景 WebP和網站版山景 WebP；UI JPG、直接轉換的 UI WebP和網站版 UI WebP；以及主視覺圖片 JPG、直接轉換的主視覺 WebP和網站版主視覺 WebP。

網站範本批次的總大小比直接 WebP 批次小 42.3%。這並不能證明品質 82 適合每個網站，而是顯示為網站用途選擇品質的重要性，可能不亞於選擇 WebP 格式本身。

內附的檢查工具回報，所有輸出都是尺寸符合預期、有效、不透明的靜態 WebP 檔案。山景 JPG 帶有 EXIF 資料區塊，而其直接轉換與網站範本 WebP 也都帶有 EXIF 資料區塊。另外兩個輸入和輸出則未帶有中繼資料區塊。兩次執行後，來源 SHA-256 雜湊值都沒有變化。

這些結果刻意限定於本組測試素材。已經最佳化的 JPG 在品質設定較高時，節省幅度可能較小、完全沒有節省，甚至產生更大的 WebP。請測量輸出；如果轉換結果未能充分改善傳送資產，不值得多保留一份版本，就應捨棄該次轉換。

結合情境解讀百分比

只有在分母清楚可見時，百分比才有意義。從很小的縮圖節省 70%，減少的位元組數可能還少於從大型主視覺節省 20%。對此批次而言，網站範本總共減少了 317,531 位元組，也就是在 HTTP 壓縮和傳輸額外負荷前約 310 KiB。山景相片是最大的來源檔，因此貢獻了最多的絕對縮減量。

也應區分檔案大小與呈現尺寸。瀏覽器可以將 1920 × 1080 的檔案顯示為 600 CSS 像素寬，但除非回應式選擇提供較小的候選檔案，否則下載的仍是完整編碼資產。反過來說，用 CSS 將 600 像素的檔案拉伸至 1200 像素，也無法重建已遺失的細節。發佈管線需要適當的編碼，也需要適當的固有尺寸。

若要進行可重複的效能稽核，請記錄原始檔與輸出檔的位元組數、確認正式環境 URL，再於具代表性的行動網路連線上測試頁面。不要根據本機檔案大小比較，聲稱固定的載入時間改善：延遲、快取狀態、伺服器位置、要求優先順序，以及相互競爭的資源，全都會影響訪客的實際體驗。

正確發佈 WebP

產生 WebP 檔案只完成了一半工作。頁面仍然需要有效的標記、穩定的版面尺寸、實用的替代文字，以及適當的後備政策。

HTML <picture> 元素可讓瀏覽器選擇支援的來源，同時保留 <img> 後備版本：

<picture>
  <source srcset="mountain-photo.webp" type="image/webp">
  <img
    src="mountain-photo.jpg"
    width="1440"
    height="960"
    alt="夕陽下的山間草地"
    decoding="async">
</picture>

這裡的 <img> 在沒有適合的 <source> 時提供格式備選。WebP 要求失敗（例如 HTTP 404）不會自動觸發 JPG 重試。請分別檢查兩個 URL。

將偏好的 WebP 來源放在前面，並將 <img> 元素保留在最後。width 和 height 屬性會在瀏覽器下載圖片前提供圖片的長寬比，協助版面預留正確空間。CSS 仍可使呈現的圖片具備回應式特性：

img {
  max-width: 100%;
  height: auto;
}

如果設計會提供差異顯著的寬度，請建立真正的不同版本，並使用 srcset 和 sizes，避免窄螢幕視窗下載桌面尺寸的檔案。不要虛構一個將多個寬度描述元指向同一張底層圖片的 srcset。

對於首屏以下的圖片，原生 loading="lazy" 可以延後工作，直到圖片接近可視區域。不要延遲載入很可能位於首屏以上的主視覺，或最大內容繪製圖片。web.dev 的瀏覽器層級延遲載入指南建議積極載入第一個可視區域中可見的圖片，因為延後它們可能拖延呈現，而非帶來改善。

最後，將伺服器或靜態託管服務設定為以 image/webp 傳送 WebP、對版本化資產使用長效快取標頭，並在瀏覽器開發人員工具中驗證正式環境回應。編碼再完美的檔案，如果 MIME 類型錯誤、URL 失效或沒有快取政策，也不能算完成最佳化。

在將圖片視為已發佈前，請確認這份簡短的正式環境檢查清單：

• WebP URL 可成功回應，並回報 image/webp；
• JPG 後備 URL 也能正常回應；
• 呈現的長寬比與檔案尺寸相符；
• 行動版面會收到尺寸適當的候選檔案；
• 主視覺會提早提出要求，而非延遲載入；以及
• 首屏以下的圖片不會在啟動時全都與關鍵內容競爭。

中繼資料與隱私仍是不同的議題

轉換為 WebP 並不會自動清除相片中的敏感資訊。由於安全共享處於關閉狀態，帶有 EXIF 的山景圖片在兩個經測試的工作流程中都保留了 EXIF 資料區塊。這與網站範本顯示的摘要一致：中繼資料會保留。

如果圖片將公開發佈，而內嵌的位置、裝置、作者或日期資訊會造成疑慮，請使用支援的中繼資料移除工作流程，並在完成後檢查輸出。請閱讀檔案轉換會移除 EXIF 中繼資料嗎？，了解變更格式與移除私人中繼資料之間的差異。

移除中繼資料可能會稍微減少位元組數，但隱私應是明確的發佈決策，而不是隱藏的效能技巧。請保留法律、編輯、無障礙或資產管理工作流程實際需要的任何中繼資料。

批次轉換，同時維持掌控

相同流程可擴展至較大的相容資料夾，但網站很少需要每張相片都採用完全相同的寬度。請依放置位置與預期呈現尺寸將檔案分組：

1. 從圖片集測試具代表性的樣本。
2. 如果主視覺、文章圖片、縮圖和 UI 擷取畫面的尺寸不同，請將它們分開。
3. 每個批次套用一項適當的輸出與尺寸政策。
4. 以原始比例比較第一批結果。
5. 記錄發佈檔名或使其自動化，而不是手動猜測哪個版本才是最新版本。
6. 將 JPG 來源檔保留在產生的資產目錄之外。

LocalFlux 會為每個準備就緒的項目寫入一個輸出檔。遇到失敗或格式異常的檔案時，應個別檢查，而不要假設每個 .jpg 副檔名都代表正常的 JPEG。若要了解更廣泛的圖片庫工作流程，請參閱如何在 Windows 上批次壓縮圖片。

JPG 仍可能是較好選擇的情況

如果 JPG 已足夠精簡、必要的目的地不接受 WebP，或新增 WebP 版本只會增加作業複雜度，卻無法帶來值得的位元組縮減，請繼續提供 JPG。即使目前的主流瀏覽器都支援 WebP，對於舊版內嵌 WebView、電子郵件用戶端、內容擷取系統或下游工具，後備版本仍可能有用。

請勿將 JPG 轉換為 WebP，再轉回 JPG 作為編輯循環。反覆進行有損編碼會累積損傷。請從可取得的最佳來源進行編輯，並在發佈管線接近尾聲時只產生一次傳送資產。

對於標誌、圖示、透明去背圖和邊緣銳利的圖表，請從能保留所需邊緣和 Alpha 色版的來源格式開始。現有的 PNG 轉 WebP 逐步說明專門處理這項工作。若要深入了解如何開啟和轉換 WebP 檔案，請參閱 WebP 實用指南。

常見問題

WebP 一定能讓 JPG 變小嗎？

不一定。三張測試圖片的確都變小了，但內容、來源品質、輸出品質、尺寸、設定檔和編碼器行為會共同決定結果。請比較實際位元組數。

JPG 轉 WebP 能改善圖片品質嗎？

不能。有損 WebP 可以是高效率的傳送版本，但無法復原 JPG 已捨棄的細節。它會再進行一次編碼，因此請在發佈前檢查精細細節。

網站範本有調整這些檔案的大小嗎？

沒有。三個輸入檔都已等於或低於其 1920 像素的長邊上限。它們的尺寸仍為 1440 × 960、1320 × 940 和 1920 × 1080。

轉換會移除 EXIF 中繼資料嗎？

請勿如此假設。帶有 EXIF 的山景 JPG，以及兩個經測試的 WebP 輸出，都帶有 EXIF 資料區塊。中繼資料移除功能處於關閉狀態，必須作為獨立步驟處理並驗證。

原始 JPG 會被覆寫嗎？

在此工作流程中不會。LocalFlux 會在來源檔旁寫入新的 WebP 版本，而三個轉換後 JPG 的雜湊值都與轉換前相符。

每個網站都應使用 JPG 後備版本嗎？

不一定。目前的主流瀏覽器支援 WebP，但您的受眾可能包含較舊的 WebView 或非瀏覽器系統。當相容性政策要求後備方案時，<picture> 模式可提供直截了當的做法。

只有 WebP 就足以讓頁面變快嗎？

不足以。請使用尺寸適當的回應式圖片、明確尺寸、有效快取，以及合理的載入優先順序。圖片格式只是傳送效能的一部分。

建立 WebP、測量結果，再加以發佈

可靠的工作流程很簡單：保留 JPG、在本機建立 WebP 傳送版本、以原始比例比較結果，並確認正式頁面提供的是正確資產。在本次測試中，網站用途批次在未調整任何圖片尺寸的情況下，將 469,529 輸入位元組減少至 151,998 位元組。測得的節省幅度是實用證據；保留原始檔並誠實檢查品質，才是讓工作流程安全的關鍵。

從 Microsoft Store 取得 LocalFlux，或查看支援的格式與轉換路徑。