Why Does Google Save Images as WEBP? (And How to Get JPG Instead)

You right-click an image, hit "Save image as," and expect a normal JPG. Instead you get a .webp file that won't open in PowerPoint, won't import into your CMS, and makes Photoshop complain. You didn't do anything differently. The website didn't either, necessarily — this has just been getting more common every year, and most explanations either oversimplify it or get the mechanism wrong.

Here's what's actually happening, and the four ways to get a JPG when you need one.

The real reason: it's an HTTP handshake, not a Chrome bug

Every time your browser requests an image, it sends a header called Accept that lists the formats it's willing to receive, in order of preference. A modern Chrome request looks roughly like this:

Accept: image/avif,image/webp,image/png,image/svg+xml,*/*

If the server sees image/webp in that list, it knows it can safely send the WEBP version instead of JPG or PNG — a technique called content negotiation. WEBP files run 25–35% smaller than equivalent-quality JPGs, so any site that cares about load speed has an incentive to use this. Most do, since Google has weighted page speed into search rankings for years.

This is also why the behavior felt like it appeared out of nowhere. Safari didn't support WEBP until 2020, with Safari 14. Before that, a meaningful slice of visitors — every iPhone and Mac Safari user — would have gotten a broken image if a site served WEBP-only. Once Safari joined Chrome, Edge, and Firefox in supporting the format, sites had no compatibility reason left not to switch. The shift from "rare" to "everywhere" happened in roughly that window.

There are actually two different things going on, and conflating them is why fixes that work on one site fail on another:

• True negotiation: the server keeps both a WEBP and a JPG/PNG version of every image, and picks based on your Accept header. Change what your browser sends, and you can get the JPG back.
• WEBP-only delivery: the site converted its entire image library to WEBP at some point and never kept the originals. There's no JPG hiding anywhere on their server — no header trick, no extension, and no amount of asking nicely will produce one, because it doesn't exist.

Knowing which situation you're in changes which fix is worth trying.

The four ways to get JPG instead

Ranked by how reliably each one actually works, not by which order other articles happen to list them in.

Option 1: Convert the WEBP after saving it (most reliable)

Let the save happen normally — you'll get a WEBP file — then convert that file to JPG. This works regardless of whether the site does true negotiation or WEBP-only delivery, because you're not fighting the server at all; you're just finishing the job after the fact.

The trade-off is which converter you use. Many online WEBP converters upload your file to a server, convert it there, and send the JPG back — fine for a meme, less fine for a screenshot with personal information in it. Tools that run the conversion in-browser (via the Canvas API or WebAssembly) never send the file anywhere; you can confirm this yourself by opening DevTools' Network tab during conversion and watching that no image data leaves your machine.

Best for: Almost everyone. It's the only method that works whether or not a JPG version exists on the server.

Option 2: Use a "save as" browser extension

Extensions like "Save image as Type" add a right-click option to save directly in PNG or JPG, converting on the fly before the file hits your disk. This skips the manual two-step of save-then-convert.

The catch: the extension is still just converting whatever the server sent it — if the server only has WEBP, the extension converts that WEBP to JPG for you, same end result as Option 1, just automated. It doesn't request a different format from the server. Some users also report these extensions going unmaintained or breaking after Chrome updates, since they're small side projects.

Best for: People who download images from the same handful of sites often and want to skip the manual conversion step every time.

Option 3: Force a different Accept header (advanced, unreliable)

Header-modifying extensions like ModHeader let you strip image/webp out of your browser's outgoing Accept header, which can convince a server doing true negotiation to send JPG instead.

This only works on the first category of site described above — the ones storing both formats. On WEBP-only sites, the server has nothing else to send, so it'll either serve WEBP anyway or, in some misconfigured cases, throw an error. It's also a blunt instrument: you're changing how every site you visit treats your browser, not just the one giving you trouble, and a few sites may behave unpredictably without their expected header.

Best for: People comfortable with browser internals who specifically need negotiated JPGs from a site they know keeps both versions.

Option 4: Check for a non-WEBP URL variant

Occasionally a site serves WEBP at a URL that still ends in .jpg or .png — the extension is just stale, left over from before the site switched formats. Right-click the image, choose "Open image in new tab," and look at the address bar. If it ends in .jpg but the saved file is still WEBP, try removing everything after a ? in the URL, or appending a random character after one, and reloading. Some CDN setups will return a different cached variant.

This is a low-odds trick — it depends on a specific kind of CDN misconfiguration — but it costs nothing to try before reaching for a converter.

Best for: A quick check before committing to Option 1, especially on sites you suspect migrated formats recently.

Which option should you actually use?

For most people, the honest answer is: don't fight the handshake. Let the save happen, then convert the result. It's the one method that works no matter which kind of site you're dealing with, and it's faster than diagnosing which category a given site falls into.

Edge cases: Google Images, Google Photos, and WEBP-only CDNs

A few situations that don't fit the general pattern above.

Google Images search results. Google Images sometimes labels a result with a small WEBP badge before you even click it. That badge reflects the actual format stored at the source site, independent of your browser — it's telling you in advance that this particular image has no JPG fallback, so don't expect header tricks to help once you save it.

Google Photos downloads. Some users report Google Photos handing back WEBP when downloading images that were uploaded as PNG. This is a separate mechanism from website content negotiation — it's Google Photos' own storage and compression layer choosing an output format, not your browser's Accept header. The fix is the same regardless: convert after downloading.

Batch downloads via script or ImageMagick. If you're scripting downloads rather than clicking through a browser, you control the Accept header directly, which means you can request image/jpeg explicitly and get a real answer about whether the server has one — no guessing required. For occasional one-off saves, that's overkill; for someone scraping a large image set, it's worth the extra line of code.

Mobile browsers. The same content-negotiation logic applies on iOS and Android Chrome, Safari, and most mobile browsers — the fixes above work the same way, though "save as" extensions generally aren't available on mobile, leaving convert-after-saving as the most practical option.

Frequently asked questions

Does this happen in Firefox or Safari too, or just Chrome?

It happens in any current browser, since all major browsers now advertise WEBP support in their Accept header. Chrome and Edge have done this since 2014, Firefox since 2019, and Safari since 2020. If you're on an up-to-date browser, you'll see this behavior regardless of which one you use.

Why do some sites give me JPG and others only give WEBP?

It comes down to whether the site kept the original files. Sites doing true content negotiation store both formats and choose based on your Accept header. Sites that fully migrated to WEBP and deleted the originals have nothing else to serve, so there's no JPG to negotiate for.

Will converting WEBP to JPG lose quality?

A small, usually invisible amount. You're re-encoding an already-compressed file, so some technical loss is unavoidable. At 90% JPG quality, it's imperceptible in normal viewing. If the original WEBP was lossless, converting to PNG instead avoids any further compression loss.

Can I stop Chrome from accepting WEBP entirely?

Not through a settings menu — that option was removed years ago. A header-modifying extension can strip WEBP from your Accept header, but many servers ignore the header and serve WEBP regardless if that's the only format they have stored, so it's an unreliable fix.

Why does Google Images specifically show a WEBP icon on some results?

It's flagging the actual format at the source site before you click through, independent of your own browser settings. A WEBP-badged result means the source has no JPG fallback stored, so saving it will give you WEBP no matter what.

Is WEBP actually better than JPG, or is this just Google pushing its own format?

Both are true. WEBP genuinely produces smaller files at comparable visual quality, which is a real benefit for page load speed. It's also true that Google created the format and has a direct interest in faster page loads, since speed factors into search rankings. A format can be technically sound and also self-interestedly promoted at the same time.

Why did this start happening more in the last few years?

Safari adding WEBP support in 2020 removed the last major compatibility reason for sites to avoid WEBP-only delivery, right around the time Google started weighting page speed more heavily in search rankings. Both pressures landed close together, which is why the shift felt sudden rather than gradual.

The bottom line

Chrome isn't broken and you didn't change a setting. Your browser is telling servers it can handle WEBP, and most servers take it up on that offer because smaller files mean faster pages. Some of those servers still have a JPG tucked away if you ask the right way; plenty don't, because they deleted the original the day they migrated.

The practical move is to stop trying to diagnose which kind of site you're on and just convert after saving — it works either way, takes seconds, and doesn't depend on guessing right about a server's storage you can't see. Save the extensions and header tricks for when you're doing this often enough that automating the step is worth the setup.