Why Do Images Save as WebP (and How to Stop It)

Why do images save as WebP instead of the JPG or PNG you expected? Because the website already made that choice: your browser lists image/webp in the Accept header on every image request, and the server or CDN swaps in the smaller file automatically, no click or setting involved. Lossy WebP runs 25 to 35% smaller than a JPEG at the same visual quality, which is the entire incentive.

I see this on my own machine constantly: right click, save image, and a .webp file lands in the folder even though nothing about the request asked for it by name. This page proves the mechanism with an actual request and response, shows the trick where a .jpg URL can still hand you WebP bytes, measures exactly what converting back costs in kilobytes, and lays out the real per-browser fix, the deeper technical half of the WebP and AVIF hub.

Why Do Images Save as WebP?

Your browser decides this before you ever click save. Every image request a browser makes carries an Accept header, a line in the request that lists which image formats the browser can decode, and Chrome, Edge, Firefox, and Safari have all listed image/webp on that line for years. A server, or the CDN sitting in front of it, reads that header and, if WebP is on the list, can hand back the WebP version of the same picture instead of a heavier JPEG or PNG, saving real bandwidth on every view across every visitor whose browser supports it (Google WebP FAQ). Nothing about your click changed anything. The file that reaches your browser is whatever the server decided to send, and "Save image as" writes exactly those bytes to disk, extension included.

Google built WebP specifically to make this trade attractive: lossy WebP typically runs 25 to 35% smaller than a JPEG at the same visual quality, and lossless WebP runs about 26% smaller than PNG (Google Developers, WebP). A site serving millions of images a month saves real money and real load time by defaulting to WebP wherever a visitor's browser allows it, and images downloading as webp instead of the older formats is that same saving showing up in your downloads folder rather than on some engineer's dashboard.

How Does the Accept Header Actually Prove It?

Open your browser's network inspector on almost any image-heavy page and you can read the exact line making this decision. A typical Chromium browser sends a request header that looks like this:

Accept: image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8

That header is a straightforward preference list: AVIF first, WebP second, then generic image types as a fallback if neither is available (MDN, the Accept header). A server built to use it checks that list once per request, sees image/webp sitting on it, and its response carries a Content-Type of image/webp along with the smaller file, all before a single pixel reaches your screen. This is HTTP content negotiation working exactly as designed, not a bug report waiting to happen, and it explains why the same URL can hand two different visitors two different files: one whose browser lists WebP gets WebP, and an older browser that never added it still gets the original JPEG or PNG from the same address.

Firefox, Safari, and every Chromium browser, Chrome, Edge, Opera, and Brave among them, have carried image/webp on this list since at least 2019, so in 2026 the exceptions are rare: a browser genuinely too old to list WebP, or a site that never bothered checking the header and serves the same format to everyone regardless of what they can handle.

How Much Size Are You Giving Up by Converting Back to JPG or PNG?

Real bytes, not a percentage you have to take on faith. The homepage demo on this site takes a 497 KB JPG down to a 214 KB WebP at quality 80, 56.9% smaller with no visible difference at normal zoom. Run that math in reverse and you can see exactly what a browser extension or a converter gives back when it turns that WebP into a JPG again: since lossy WebP saves 25 to 35% over an equivalent JPEG, reversing that saving means the reconverted JPG lands roughly 33 to 54% larger than the WebP it came from, which puts a 214 KB WebP back around 230 to 266 KB as a JPG.

That 230 to 266 KB range is still smaller than the original 497 KB JPG, because quality 80 already threw away some detail the reconversion cannot recreate. Converting a WebP back to JPG does not undo the compression that already happened, it just repackages what is left in a format more software accepts. Run your own file through the WebP to JPG converter if you want your own real number instead of a range, since the source photo changes exactly how much you get back. The honest tradeoff stands either way: every workaround that stops WebP downloads, and every conversion after the fact, trades some of that original saving back for compatibility.

Does Every Site Do This, or Only Some?

On nearly every site that serves meaningful traffic, because both the browsers and the infrastructure now default to yes. CDNs sitting in front of most large sites, Cloudflare among them, offer automatic image optimization that can rewrite JPEG and PNG requests to WebP on the fly whenever the Accept header allows it, with no action required from the site owner beyond leaving the feature switched on. Google's own guidance around page speed rewards faster image delivery, and a smaller file is a faster file, so sites that care about search ranking have a second, separate reason to keep this switched on beyond the bandwidth bill alone.

If it feels like every image on your phone does this, that is not a coincidence specific to your device. Android's browsers are Chromium underneath, so they carry the same Accept header as desktop Chrome, and Google Photos serves WebP thumbnails and shared links by default for the identical bandwidth reason. Chrome's Data Saver mode, when a person turns it on, pushes further still, routing images through Google's own compression proxy and often returning even smaller WebP files than a normal request would. None of this is unique to any one app; it is the same header-driven decision running everywhere WebP is supported.

The images that still arrive as JPG or PNG usually fall into a short list: a CMS or platform that never turned on format negotiation, a thumbnail already small enough that the WebP saving is not worth the extra encode step, or, increasingly rarely in 2026, a visitor on a genuinely outdated browser. None of that is a broken site. It is a site that has not opted into the same optimization most of the web already has.

Why Does a .jpg URL Sometimes Deliver a WebP File?

Because a URL is just a label, and the label does not have to match the bytes behind it. A path ending in .jpg tells you what a site's developer originally named the resource, not what format the server actually sent for this particular request. Content negotiation happens on top of that same URL: the server or CDN can serve WebP bytes at a path that still reads photo.jpg, because nothing about content negotiation requires the URL to change when the format does.

This is also exactly why the well meaning tip of backspacing "webp" in a browser's Save As box and typing "jpg" instead does not work: it changes the label the browser is about to write, not the format the server already sent, so the saved file still holds WebP data under a .jpg name. If you want to check what a file actually is rather than trust its name, open it in a plain text or hex viewer and look at the first few bytes: a real WebP file starts with the letters RIFF followed later by WEBP, regardless of what its filename claims, while a real JPEG starts with the bytes FF D8. That one check settles the question faster than any rename ever could.

How Do You Stop Images From Saving as WebP?

There is no single switch that turns this off everywhere, because the decision happens on the server's side of the request, not yours. Chromium browsers, Firefox, Safari, and mobile browsers each need a different workaround, and every one of them either strips WebP off your outgoing Accept header or converts the file after it lands, since no mainstream browser ships a built-in "never send me WebP" toggle in 2026.

Chrome, Edge, and Opera GX (Chromium browsers)

None of the Chromium family exposes a settings toggle for this. The two workarounds people actually use are a header-modifying extension, such as Simple Modify Headers, which strips image/webp out of the outgoing Accept header so the server never offers WebP in the first place, or a save-time extension, such as Save Image as Type, which intercepts the download and re-encodes it to JPG or PNG on the way to disk. Stripping the Accept header is the closer fix to a real off switch, but it can also break sites that assume WebP support exists and serve a broken fallback instead, so treat it as a workaround, not a setting any of these browsers endorse.

Firefox

Firefox has shipped native WebP decoding since version 65 (caniuse, WebP), so there is no leftover about:config flag that quietly disables support the way some older preferences once could. Firefox users who want to stop images from saving as webp generally reach for the same kind of Accept-header extension Chromium users do, community tools built for exactly this edit, since the underlying fix is identical: strip WebP off the header before the request leaves your machine.

Safari (Mac and iPhone)

Safari's extension ecosystem rarely exposes raw request-header editing the way Chromium's does, so there is no equivalent widely used header-stripping extension on Mac or iPhone. The realistic fix on Safari is converting the file after it saves rather than trying to intercept the request, which is also the only option that works identically on both the desktop and mobile versions of the browser.

Android

Android's browsers inherit whatever engine they are built on, so Chrome for Android follows the same Chromium behavior, and the same Accept header, as its desktop counterpart. There is no separate mobile setting, and the header-stripping extensions that work on desktop Chrome generally do not have an Android build, which is why converting the saved file after the fact, rather than trying to stop the download in the first place, is the more realistic fix on a phone.

Does Renaming a WebP File to .jpg Actually Convert It?

No, and this is worth stating plainly because it is the single most common wrong fix. Renaming only changes the four characters after the dot; it does not touch the compressed pixel data stored inside the file. A file called photo.jpg that is still WebP data internally will fail to open, or open corrupted with garbled color blocks, in any software that reads a file's actual contents instead of trusting its extension.

The only way to get real JPG or PNG bytes is an actual export, save-as, or conversion step, one of the workarounds already covered above, never a rename. If a program does open the renamed file successfully anyway, it is because that program peeks at the real file signature rather than trusting the extension, not because the rename did anything to the underlying data.

Should You Keep the WebP, or Convert It?

Keep it if the file is only ever going to live on the web: every current browser displays WebP natively, and it is the smaller file for the same visual result, so there is nothing to gain by converting something that will only ever be viewed in a browser tab. Convert it the moment the destination is not a browser: an upload form that lists only JPG and PNG, an older desktop program, or a print shop's intake system that explicitly rejects WebP. That rejection is about the destination's limits, not a flaw in the file you saved.

If your actual goal is just to save an image as jpg instead of webp for one picture right now, the fastest route is still a straight conversion rather than fighting the Accept header, and it takes about as long as opening an editor, without needing the editor.