How to Save a WebP as JPG in Chrome: Every Route That Actually Works

Why Chrome handed you a .webp

Chrome did not convert your image. The website's server chose to send WebP, Chrome downloaded those bytes, and Save image as wrote those same bytes to your disk. The browser is a courier here, not a converter.

The mechanism is server-driven content negotiation. Your browser announces what it can display in the HTTP Accept header, and the server picks the best match it has. MDN's content negotiation reference puts it plainly: the browser sends headers describing its preferences, and "the server uses them as hints and an internal algorithm chooses the best content to serve to the client." Sites can also make the choice in markup, with <picture> and srcset offering a WebP source ahead of a JPEG fallback. Either way, the decision was made on the server before Chrome ever saw the file.

This is why the common explanation is backwards. You will read that Google "made the transition" to WebP and that Chrome now saves images in its own format. That is the wrong end of the pipe. A site that serves JPEG will hand you a JPEG in Chrome, and a site that serves WebP will hand you a WebP in Firefox and Safari too.

It is also very common now. W3Techs measures WebP on 22.0% of all websites as of September 2026, with AVIF at 1.7% and climbing. On the support side, caniuse puts WebP at 96.82% of global browser traffic. Site owners serve it because it works nearly everywhere and, per web.dev's long-standing figure, WebP files typically come in 25 to 35% smaller than the equivalent JPEG or PNG. That page carries a 2018 date and is still the canonical web.dev reference, so treat the range as a rule of thumb rather than a fresh benchmark, but the direction has not changed.

There is no Chrome setting for this. Google's own download settings documentation covers download location, prompting, automatic downloads and PDF handling, and nothing that converts image formats. The definitive confirmation is in Chromium's own tracker, where Unsplash filed Provide a way for users to download JPG/PNG from AVIF/WebP source files in May 2024. It is still open, still marked Feature Request with no status update, and a Microsoft engineer's reply on the thread states the behavior in one line: "Chrome will download whatever the URL of the image returns." Mozilla has had an equivalent request open since June 2020. Browsers have been asked for this for over six years and none of them has shipped it.

There is a genuine grain of truth in the "Chrome changed something" theory, though, and it is worth knowing because it explains the timing. The same thread pins it down: a change that landed in December 2021 made Chrome start sending the Accept header when you choose Save image as. Before that, the save request did not advertise WebP support, so plenty of servers answered it with a JPEG even though the page itself had displayed a WebP. After it, the save request looks like any other image request and gets the same modern format back. Chrome did not start converting your images. It started asking the same question twice, and getting the same answer both times.

That distinction also tells you where the fix has to live. Since the format is chosen by the server before the bytes exist, nothing on your side can change what arrives. You can only re-encode what you were given.

The rename trap, and why it keeps getting published

Renaming photo.webp to photo.jpg does not convert the file. It changes the label on the box, not what is in it, and every byte of WebP encoding stays exactly where it was.

A file's extension carries no information about how the data inside is encoded. WebP files identify themselves with a signature at the very start of the file: the WebP Container Specification requires that "a WebP file MUST begin with a RIFF header with the FourCC 'WEBP'", which on disk is the bytes 52 49 46 46 (RIFF), a four-byte length, then 57 45 42 50 (WEBP). Any program that reads those first twelve bytes knows what it is holding regardless of what you called it.

That leaves you with three possible outcomes, all bad:

• The app sniffs the header and opens it anyway. Looks like a win. You now have a WebP file named .jpg sitting in a folder, and the problem resurfaces the next time you hand it to something stricter.
• The app trusts the extension and chokes. You get "this file is damaged" or "unsupported format" on a file that is neither.
• An upload form validates properly and rejects it. Marketplace and CMS uploaders are the usual culprits, and their error messages rarely explain why.

The reason this advice persists is that outcome one happens often enough to look like success. It is the single most repeated piece of bad guidance on this topic, and at time of writing it appears in the top editorial result Google serves for the question. If someone tells you to rename the file, they have not converted anything.

Route 1: copy, paste, save (nothing to install)

The fastest route needs no extension, no upload and no software you do not already have: right-click the image and choose Copy image instead of Save image as, then paste it into any image editor or document and save from there as JPEG.

The difference matters. Save image as writes the downloaded file. Copy image puts the decoded picture on your clipboard, which is to say the actual pixels rather than the WebP container. web.dev's clipboard guidance notes that modern browsers support copying images to the clipboard as PNG and SVG, so what lands in your editor is a normal raster image with no WebP anywhere in it. Paste into Paint, Preview, Photoshop, GIMP, Figma, Google Docs or Word, then save or export as JPEG.

Two things worth knowing before you rely on it:

• Metadata does not survive. The clipboard carries pixels, so EXIF, GPS coordinates and copyright fields are gone. For a picture you are about to publish that is usually a feature rather than a loss, and it is worth understanding what image metadata actually exposes before you reattach any of it.
• You get the image as the page loaded it. If the page is displaying a small preview that links to a larger file, copy the preview and you get the preview. Open the full image in its own tab first when resolution matters.

For one image, this is a ten-second job and it is almost always the right answer. The reason nobody mentions it is a mystery to us: we read the page-one results for this question on September 21, 2026, and not one of them brings it up.

Route 2: the apps already on your machine

Every current desktop operating system can open a WebP and save a JPEG without installing anything, which makes this the reliable fallback when the clipboard route is not practical.

• Windows 11 and 10: open the file in Paint, then File > Save as > JPEG picture. Photos will also do it via Save as copy. Right-click the file in Explorer and choose Edit to jump straight into the editor.
• macOS: open in Preview, then File > Export, and set Format to JPEG. The quality slider in that dialog is a real re-encode control, so leave it high unless you are deliberately shrinking the file.
• Linux: GIMP handles it through File > Export As, and if you have ImageMagick installed, magick input.webp output.jpg is a one-liner.

The honest caveat is volume. These tools are built around one file at a time, and the frustration shows up wherever people discuss this. In a Microsoft Tech Community thread on this exact question, the user's complaint is not that Preview cannot do it: "I tried to export them one by one using Preview, but it was too troublesome to do so many times." The replies send them to Automator, PowerShell and IrfanView, and a later comment lands the real objection to all three, that "not everyone is comfy using the terminal."

If you have one image, use Route 1 or Route 2 and stop reading. If you have forty, keep going.

Route 3: adding your own item to the right-click menu

A Chrome extension cannot change what Chrome's built-in Save image as does. It can only add its own entry alongside it, and every extension in this category works the same way.

This is a platform constraint, not a design choice. The chrome.contextMenus API lets an extension add items to the right-click menu, and reading the image bytes requires host permissions for the sites you use it on. Chrome's native menu items are not extensible. One of the extensions currently ranking on page one for this question says so in its own store description: "it's not possible to modify the behavior of chrome's native 'Save image as...' context menu option."

So the question is not whether to use an extension, it is which one, and there are four things worth checking before you grant any extension permission to read the pages you visit:

1. The last-updated date. Image handling in Chrome changes. An extension that has not shipped in a year is a maintenance risk.
2. The rating, and the number of ratings. A high average from six people tells you nothing.
3. The permissions. Host permissions let an extension read page content on the sites they cover, which is what makes fetching the image possible and is also a lot of access. Prefer one scoped to the site you are on over one that asks for every site you visit.
4. The privacy disclosure. Chrome Web Store requires every listing to post a privacy policy, state a single purpose and complete its data-handling disclosures. Google's user data policy is explicit that "any discrepancies between the developer dashboard disclosures, your privacy policy, and the behavior of your item would be a violation." Read the Privacy practices tab, not just the description.

Those criteria are not academic. We captured the store listing for the WebP extension Google ranks on page one for this query on September 21, 2026: 4,000 users, an average of 1.8 out of 5 from 18 ratings, version 1.2, last updated on July 11, 2024. Google is surfacing an app-store listing on an editorial question because the intent genuinely includes "something in my right-click menu", and the best thing it has to offer has been rated 1.8 and untouched for fourteen months.

We will be straight with you about our own: the Mochify extension is new. Version 1.3.1 shipped on September 20, 2026, and its install base is small enough that it has no ratings yet. Judge it on the criteria above like anything else.

The Mochify workflow: right-click any image

The Mochify Chrome extension is a Magic Flow surface. You right-click an image on any page and describe the result you want in plain language, rather than hunting for the setting that produces it.

Under the hood Magic Flow is a two-step pipeline: a language model (currently Mistral Small 4) parses what you asked for, then our C++ image engine executes it. It is the same Magic Flow that runs in the web app, in the CLI with -p, and on both MCP servers, so the phrasing you learn in one place works in the others. There is more on how the natural-language layer works in our guide to natural-language image compression.

See it in action

The whole loop takes one right-click and one sentence, which is easier to watch than to read about. The recording below runs the job this guide is about: find a WebP on a live page, right-click it, ask for a JPG, get the file.

Measured on that same run:

Two honest notes on that table. Size change between WebP and JPEG depends heavily on what the picture is, so a photograph and a flat graphic will not behave the same way, and the row above names which one was measured. And the time is the round trip you actually experience, from right-click to file in hand, not encoder time.

Should you convert to JPG at all?

Convert when the destination forces your hand. The usual list is older desktop software, print workflows and prepress, a few marketplace and CMS uploaders that validate on extension, and colleagues on machines you do not control. Those are real constraints and JPEG is the correct answer to all of them.

Two things to get right when you do convert:

• Convert once, from the best source you have. Web images are almost always lossy WebP, and JPEG is lossy too, so converting runs the picture through a second round of compression on top of the first. It is usually invisible at sensible quality settings, but chaining conversions is how images end up looking soft and blocky. If you can get the original from the source rather than from the page, do that instead.
• If the image has transparency, JPEG is the wrong target. JPEG has no alpha channel, so a transparent background becomes solid, typically black or white. Convert to PNG instead, or keep the WebP.

AVIF is the same story one format along, at 1.7% of sites today and rising, and it lands in the same place: you will right-click something, get an .avif, and find fewer apps that open it. We cover that case in what to do when a site hands you an AVIF, and our free AVIF converter handles the file itself. If you are choosing what to standardize on rather than firefighting a single file, start with what to use in 2026: WebP, AVIF or JPEG XL and our guide to next-gen formats.

Cheat sheet

The 30-second version: the site sent WebP, not Chrome. Renaming does nothing. Copy image and paste is the fastest fix for one file. For a folder, use a converter. Keep the WebP if the destination accepts it.

FAQ