What is WebP? It is a modern image format from Google that makes photos and graphics smaller than JPEG and PNG while looking the same, with transparency and animation built in. AVIF is the newer rival, based on the AV1 video codec, and it usually compresses even harder. Both now work in every major browser.
Most people do not choose WebP; it arrives. You right-click a product photo, pick Save Image As, and get a .webp file your photo editor shrugs at. I run both formats every day through the compression engine behind imagecompressor.tools, and the demo on the home page is exactly this conversion: a 497 KB JPG becomes a 214 KB WebP at quality 80, 56.9 percent smaller, with no change you can see. This page is the hub for both formats. Here is where each fits before the sections go deep.
| If you want to | Use |
|---|---|
| Publish smaller photos on the web today | WebP, supported almost everywhere |
| Squeeze the last bytes out where you control delivery | AVIF, with a fallback |
| Send a photo to a person or an upload form | JPEG, the format that opens everywhere |
| Keep sharp text, logos, or transparency | Lossless WebP or PNG |
| Get rid of a .webp you were handed | Convert it, covered in the guides below |
What is WebP?
WebP is an image format from Google that packs a lossy mode and a lossless mode into one container, plus transparency and animation. A WebP file is a RIFF container holding VP8 image data in lossy mode or VP8L data in lossless mode, its MIME type is image/webp, and the extension is .webp. That one format covers jobs that used to need three.
The lossy mode borrows from video
The lossy mode is the clever part. It uses predictive coding, the same technique the VP8 video codec uses to compress a video keyframe: the encoder predicts each block of pixels from the neighboring blocks it has already encoded, then stores only the difference (Google Developers on WebP). Real photographs are locally predictable, so the differences are small and compress hard. That mechanism is why lossy WebP lands 25 to 34 percent smaller than a JPEG of the same visual quality, a saving that shows up on every page load without a quality cost your eye can catch.
The lossless mode rebuilds pixels exactly
The lossless mode works on a different principle. It rebuilds each pixel from image fragments it has already seen, falling back to a compact local palette when no good match exists, and no detail is discarded. Lossless WebP comes in about 26 percent smaller than the equivalent PNG. This is the mode for screenshots, logos, and text, the same content you would otherwise keep as PNG, and it is the reason the WebP format can replace two older formats at once.
Transparency and animation in one container
Transparency runs through both modes, and this is where WebP quietly embarrasses PNG. Adding an alpha channel to a lossless WebP costs about 22 percent more bytes, while a lossy WebP with transparency is typically about a third the size of the PNG it replaces. Animation lives in the same container too, which is why short clips that used to ship as heavy GIFs increasingly ship as WebP instead. Google publishes the format's reference tooling, the libwebp library with the cwebp and dwebp command line encoders, so the format is defined against code anyone can read rather than a spec locked in a drawer.
What is AVIF?
AVIF is the AV1 Image File Format: image data encoded with the AV1 video codec and wrapped in a HEIF container (MDN on image file types). AV1 is open and royalty-free, and so is AVIF, which means there is no patent licensing standing between you and using it. It is the younger format, and it exists for one reason: compression that beats everything before it.
Why AVIF beats JPEG and WebP on size
AVIF generally out-compresses WebP, JPEG, PNG, and GIF, and against JPEG the saving is often around 50 percent, at the cost of slower encoding. Testing from Netflix and Cloudinary showed significant size reductions versus both JPEG and WebP at matched quality (web.dev on AVIF). It also reaches past 8-bit color into the higher color depths HDR photography needs, and it carries PNG-like transparency and GIF-like animation, so it covers the same three jobs WebP does and shrinks them further.
The two caveats that keep AVIF from being automatic
Two things keep AVIF from being the default answer. First, it does not support progressive rendering. A progressive JPEG can paint a rough preview while the rest of the file arrives; an AVIF shows nothing until the last byte lands, which matters on a slow connection. Second, the ecosystem is younger: encoding takes noticeably longer than WebP, and fewer applications read or write the format, so an AVIF handed to the wrong software is a support ticket waiting to happen. Both caveats point the same way, toward serving AVIF with a fallback rather than alone.
How much smaller are WebP and AVIF, really?
For a photograph, WebP is typically 25 to 35 percent smaller than JPEG at the same visual quality, and AVIF is often around 50 percent smaller than JPEG. Those are the consistent numbers Google's own data and Mozilla's format documentation agree on, and they are enough to plan around.
| Comparison | Typical result |
|---|---|
| Lossy WebP vs JPEG, same visual quality | 25 to 35 percent smaller |
| Lossless WebP vs PNG | About 26 percent smaller |
| Lossy WebP with transparency vs PNG | Roughly a third of the size |
| AVIF vs JPEG | Often about 50 percent smaller |
The same numbers as a picture, relative to a JPEG baseline:
Rules of thumb are cheap, so here is one measured, checkable case: the demo on this site takes a 497 KB JPG and returns a 214 KB WebP at quality 80. That is 283 KB gone, 56.9 percent of the file, from an image that looks identical at normal zoom. The WebP compressor here runs the same engine with the same quality 80 default, which I treat as visually lossless for photographs. Feed it a phone photo straight off the camera and it typically comes back 60 to 80 percent smaller with no visible difference at normal size.
Why your saving will not match the table
The spread in that table is not noise; it tracks the source file. A photo already saved as a low quality JPEG has little redundancy left to squeeze, so it sits at the bottom of the range. A large, high quality original gives the encoder room to work and lands near the top. A flat graphic with few colors behaves differently again, since there the lossless mode competes with PNG rather than JPEG. The percentage is a property of your file, not a promise on a box, which is exactly why testing your own image beats reading anyone's benchmark, including mine.
Which browsers support WebP and AVIF?
Every current major browser reads both formats; the risk is old versions, not new ones. The support floors, per caniuse, look like this:
| Format | Chrome | Firefox | Safari | Edge |
|---|---|---|---|---|
| WebP | 32+ | 65+ | 16.0+ (14 partial) | 18+ |
| AVIF | 85+ | 93+ | 16.4+ (16.1 partial) | 121+ |
WebP's story is effectively finished: Chrome has read it since version 32, and Safari, the last holdout, completed support at 16.0 (caniuse WebP). AVIF has one number worth staring at: Edge only shipped full support at version 121, which is recent history, and Safari waited until 16.4 (caniuse AVIF). Browsers that never updated, embedded webviews, and corporate machines pinned to old versions all still exist.
The standard answer is a fallback chain through the <picture> element: offer AVIF first, WebP second, and JPEG or PNG as the floor, and the browser takes the best one it understands (MDN on image file types). On your own site that is cheap insurance. Off your own site, assume nothing: upload forms, office software, and government portals routinely reject anything that is not JPEG or PNG, no matter what a browser could display.
When should you use WebP, and when AVIF?
Use WebP as your default for images you publish on the web, and reach for AVIF when you control the delivery pipeline and want the smallest possible files. That is the whole decision, and the reasoning is compatibility versus compression.
WebP is the safe default
WebP earns default status because its support is now universal enough to serve without thinking, and the 25 to 35 percent saving over JPEG is pure gain on every page load. For a WebP vs JPG choice on the open web, WebP wins on size and gives up nothing that costs you, since it also does transparency and animation JPEG cannot. It is the format I reach for first for anything headed onto a web page.
AVIF wins where bytes matter most
AVIF wins where bytes matter most: hero images, photo-heavy pages, HDR content, and image CDNs that encode once and serve millions of times. The slower encode is irrelevant when it happens once in a build step, and the fallback chain covers the stragglers. That is the AVIF vs WebP tradeoff in one line: AVIF for maximum savings you control, WebP for reach.
When neither belongs
Neither format belongs in email attachments, documents, or anything you hand to another person's software. Photos you send to people should stay JPEG, the format whose entire value is opening everywhere; JPEG explained covers that half of the story. Graphics headed into upload forms and office suites are safest as PNG, the compatibility king covered in PNG explained. The rule is boring but it saves headaches: pick the format for where the file is going, not for the smallest number, because an image that will not open is not smaller, it is broken.
Are WebP files safe?
Yes. A WebP file is image data, not a program, so it cannot run code on your machine any more than a JPEG can, and the format has no history of being dangerous by design. The question comes up because a lot of people meet WebP as a surprise download and distrust what they did not choose, which is a fair instinct and a separate issue from real risk.
The one incident worth knowing about was a 2023 security flaw, not in the WebP format but in libwebp, the reference library many apps use to decode it. A malformed file could trigger a memory bug in that library, and because the same code ships inside browsers and messaging apps, the patch went out fast and wide. That is worth understanding for what it was: a bug in one piece of decoding software, fixed in days, not a property of the format that lingers in every file.
The practical takeaway is the same as for every format: keep your browser and apps updated and the decoder that opens your images stays current. The format itself is fine, and opening a .webp you were sent is no riskier than opening any image you did not create.
Why do images save as WebP when you never asked for it?
Because the website served WebP, and your browser saves the bytes it was sent. Sites detect that your browser accepts WebP and deliver it to cut bandwidth, so the JPG you think you are saving may not exist on the server at all. This is the single most common WebP complaint, and it is not a setting you got wrong.
There is no reliable browser toggle that refuses the format, so the fix is to convert the file after it lands. That takes seconds, and this hub has a whole shelf of escape-hatch guides for it below: WebP back to JPG or PNG, WebP to GIF for the animated case, and the no-converter tricks for when you need a JPG in the next thirty seconds. The annoyance is real, the format is not the enemy, and the conversion is quick once you know which route to take.
How do you convert to WebP and AVIF, and back out?
Drop a file in, pick the output format, and download; the compressor on this site reads and writes JPG, PNG, WebP, and AVIF, and converts between any of them. Quality defaults to 80, and EXIF metadata, the hidden block where your camera writes GPS coordinates, the device model, and the timestamp, is stripped by default, so a photo does not carry its GPS coordinates out into the world by accident. For the AV1 side specifically, the AVIF compressor runs the same engine with AVIF output.
On the command line, Google's libwebp ships cwebp for encoding and dwebp for decoding, and they are the reference implementations the format is defined against. AVIF tooling is thinner and slower, which is one more reason most people let a build pipeline or a converter handle it rather than encoding by hand. If you serve your own site, the pattern to copy is a single <picture> block that lists an AVIF source, then a WebP source, then a plain JPG, and lets each browser pick the best file it can read.
Getting out of a modern format is the more common emergency. To turn a stray .webp into something your old software accepts, convert it to a standard JPG and the file opens everywhere again. The guides below cover every direction, into these formats and back out of them.
Every WebP and AVIF guide on this site
Seventeen spokes hang off this hub. Pick by the job in front of you.
Understand the formats:
- What is WebP, the complete answer goes deeper on the format itself.
- What is AVIF does the same for the newer format.
- Does WebP support transparency answers the alpha question with numbers.
- Can WebP be animated covers the GIF-replacement case.
- Can ChatGPT read WebP images settles whether AI tools accept .webp uploads.
Compare before you commit:
- WebP vs JPG and PNG puts the old formats against the new one.
- AVIF vs WebP settles the fight between the two moderns.
Get out of WebP:
- How to open a WebP file is the first-contact guide.
- Convert WebP to JPG is the most-walked escape route.
- Save a WebP as JPG without a converter covers the built-in tricks.
- Convert WebP to PNG keeps transparency intact on the way out.
- Convert WebP to GIF handles the animated case.
- Why images save as WebP explains the download surprise in full.
- Save Discord emojis as PNG fixes a specific, popular annoyance.
Adopt the modern formats:
- Convert JPG to WebP moves your photos over.
- Convert PNG to WebP moves your graphics over.
- Convert an image to AVIF gets you onto the smallest format.
The sibling pillars cover the formats these replace: JPEG explained for the lossy baseline, and PNG explained for lossless and transparency.