Chrome 把图片存成 .webp，是因为网站发来的就是它。你右键"图片另存为"时，Chrome 不做任何转换——它把服务器交付的字节原样写盘，而服务器交付的是 WebP。不存在什么隐藏很深的 Chrome 设置在捣鬼，所以你也找不到能关掉它的开关。最快的解法是存下来再转换：我们的 WebP 转 JPG 工具在浏览器里运行，不上传任何东西，存下来的 WebP 几秒钟就能变成正常的 JPG。想弄明白为什么会变成这样，或者想从源头掐断，接着往下看。
Chrome 为什么存 WebP：内容协商
浏览器每次请求图片，都会附上一个 Accept 头，列出自己能解码的格式。现代 Chrome 发的是类似 image/avif,image/webp,image/png,... 的东西——一封公开邀请函。服务器看着这份清单，发现 WebP 受欢迎，就发 WebP，因为这是它被允许发送的最小文件。网站是故意这么做的：WebP 能把图片带宽砍掉四分之一甚至更多（WebP 的诞生解释了 Google 当初为什么造它）。
同一支舞的老版本发的是 JPEG，因为那是浏览器当年声明的全部。"图片另存为"没有任何变化——这个菜单项历来都是收到什么存什么。变的是收到的东西。而且这个机制已经在重演：Chrome 也声明了 AVIF 支持，所以有些网站上存下来的文件现在是 .avif——更新、更小，在浏览器之外的支持比 WebP 还差。
你可以亲眼看它发生。打开 DevTools（F12），切到 Network 标签，刷新页面，点开图片请求，看响应头。你会看到 content-type: image/webp。这个文件在到达你的下载文件夹之前很久，就已经是 WebP 了。
解法一：先存，再转（可靠的那个）
存下 WebP，拖进 WebP 转 JPG 工具，下载 JPG。整个循环几秒钟，对任何网站无例外地有效，而且——因为转换在本地进行——你的文件永远不会经过别人的服务器。攒了一整个文件夹的 WebP？一次全拖进去，结果打包成一个 ZIP 下载。完整步骤见 如何把 WebP 转成 JPG。
如果图片带透明背景且你想保留，改用 WebP 转 PNG 工具——JPG 会把透明度压到白底上。
这是能跟着文件走的解法：JPG 在你转发的任何人那里都能打开，这一点比听起来更重要——WebP 文件为什么打不开是最常见的后续问题。
解法二：改网址（部分 CDN 有效）
很多图片 CDN 按网址决定格式。在新标签页打开图片，如果地址以 .webp 结尾，试试改成 .jpg 或 .png 再刷新。有些 CDN——尤其是做实时转换的——会愉快地重新编码，按你要的格式交付；还有一些接受 ?format=jpg 这类查询参数。另一些则直接回 404，因为 WebP 文件是唯一存在的版本。
花三秒钟试一下是值得的。把工作流建立在它上面则不值得。
解法三：让 Chrome 不再请求 WebP（越来越脆弱）
既然服务器跟着 Accept 头走，理论上可以让 Chrome 不再声明 WebP 支持。实际上路子已经变窄了。像"Save image as PNG"这类扩展走的是更友好的路线：拦截下载并自动转成 PNG，文件落盘时已经是转好的。改写 Accept 头的扩展也存在，但有些网站完全跳过协商，硬编码返回 .webp 地址——什么头部技巧都改变不了这一点。而且凡是碰请求头的东西，都会在 Chrome 更新扩展规则时悄无声息地坏掉。
如果走这条路，先在你在意的那个具体网站上测过，再信任它。
解法四：截图（最后手段）
是的，截图完全绕开了格式问题。它也扔掉了原始分辨率、所有内嵌元数据和一切透明度，并且捕获的是页面为了展示而做过的压缩和缩放。收个梗图，可以。要复用的产品图，同样的十秒钟还是花在解法一上更值——转换出来的文件是真正的图像，而不是图像的照片。
这一切存在的更深层原因，是 WebP 对网站确实更好，所以 WebP 文件的供应只会越来越多——同一个支持缺口也是老表单拒收 WebP 上传的原因。在桌面世界的其他部分追上来之前，把转换器放在离你一个标签页的地方：存下图，拖进去，然后继续过你的日子。