如何在 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 像素宽显示，但除非响应式选择提供了更小的候选文件，否则下载的仍是完整编码素材。相反，将 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" 可以在图片接近视口前避免加载工作。不要延迟加载可能位于首屏的主视觉图或 Largest Contentful Paint 图片。web.dev 的浏览器级延迟加载指南建议对首个视口中可见的图片进行积极加载，因为延迟它们可能会拖慢渲染，而不是带来帮助。

最后，配置服务器或静态主机以 image/webp 发送 WebP，为带版本号的素材使用长期缓存标头，并在浏览器开发者工具中验证生产响应。文件编码得再完美，如果 MIME 类型错误、URL 损坏或没有缓存策略，也不算完成优化。

在认为图片已经发布前，请确认这份简短的生产检查清单：

• WebP URL 成功返回，并报告 image/webp；
• JPG 备选 URL 也能正常响应；
• 渲染宽高比与文件尺寸一致；
• 移动布局获得尺寸合适的候选文件；
• 主视觉图被提前请求，而不是延迟加载；以及
• 首屏以下的图片不会在启动时全部与关键内容争抢资源。

元数据和隐私是独立问题

转换为 WebP 不会自动清理照片。由于 安全共享处于关闭状态，带 EXIF 的山景图在两种测试流程中都保留了 EXIF 数据块。这与网站模板的可见摘要一致：保留元数据。

如果图片要公开发布，而其中嵌入的位置、设备、作者或日期信息令人担忧，请使用受支持的元数据移除流程，并在之后检查输出。阅读文件转换会移除 EXIF 元数据吗？，了解更改格式与移除私人元数据之间的区别。

移除元数据可能会略微减少字节数，但隐私应当是明确的发布决策，而不是隐藏的性能技巧。保留法律、编辑、无障碍或素材管理流程确实需要的元数据。

批量转换并保持控制

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，或查看支持的格式和转换路径。