So as every time I read something decrying how webp is allegedly "annoying", the conclusion is that the problem was never about webp itself but the tooling and ecosystem to handle it
Windows 10 support went EOL one year ago. It is an archaic operating system, so no doubt, it does not support modern technology out-of-the-box. Nevertheless, it can be modified to add such support with trivial effort.
Firefox actually silently and automatically converts images to webp in some cases when you Save As them, with no option to revert to the format you see in the DOM. It’s fucking infuriating. I hate webp because the support is so spotty.
I don't think that's firefox doing it? I'd guess it's some CDNs doing the conversion. Or the URL says .jpg but when you look at the mimetype sent by the server it's actually webp. Extentions are meaningless for browsers.
No, the server is just sending the file named 'foo.jpg', but encoded as a webp with webp mime type, so when you save the file it defaults to the webp extension cause it ends up treating the filename as a blob of text without an expected extension for the file type.
This would cause the downloaded file to have incorrect file extension because such services don't configure the Content-Disposition header properly, and you still may have lots of improperly named files unless you realize that the file content doesn't match its extension.
Annoyingly, this doesn't work for a whole lot of websites that insist on serving webp, they just ignore the header. Some of them have bespoke workarounds like adding ?format=original on fandom wikis, with some the server will just never serve you anything other than webp.
To not be annoying the tools don't have to just exist somewhere, they need to be ubiquitous. For example, If I'm looking to upload an image as an avatar on a website, will webp be supported? It's unlikely, even if the site itself might ultimately serve up a webp file. So then I'd have to use a tool to convert it to a more ubiquitous format before uploading it, likely doing a bunch of lossy conversion along the way. That's annoying.
Yeah it's purely the fault of the tens of thousands of application devs that have been too stupid to recognize the obvious and immense benefits of webp over existing widely adopted formats /s
Is there a real distinction? It can be a great format, but if actually using it sucks then in practice it's a pain to use/encounter. (I don't actually have this problem personally - all my apps seem to handle it fine - but the argument seems reasonable.)
Yes, it's important to distinguish annoyances of the codec from annoyances of the ecosystem.
Ecosystem being slow to adopt it is something that can be fixed or improved, but also more importantly (given jpegxl & avif comparisons) are things that will impact any new image format.
Meanwhile annoyances of the codec tend to be things that are dramatically harder to deal with. Like HEIC being a license minefield and also slow as shit. Or that many of these newer image codecs do not have ways to work with them in a memory efficient manner like jpeg does (see eg libjpeg-turbo's sample size & skip scanline options). Or WebP insisted on being in a RIFF container for... uh... absolutely no fucking reason whatsoever afaict. Fortunately RIFF is so trivial that this overhead doesn't actually matter in practice, but then HEIC & AVIF dials up the annoying container bullshit to 11 thanks to their video heritage with ISOBMFF
Perhaps it's a matter of who hits the pain point? Ugly specs make annoyed devs, licensing problems make distributors unhappy, and ecosystem issues leave users unimpressed. (With some spillover between categories, of course.)
well that depends on the size of the image. But a modern cell phone is shooting 50mp+, and at that size you're talking 50-200ms for a jpeg vs. a couple seconds for HEIC. Which is borderline instant-feeling vs. extremely not instant.
HEVC intra is definitely not 10-20x slower than decoding VP8 intra, so something is way off with your numbers. That's on the order of comparing HM at -O0 against an actual VP8 decoder.
It seems much harder to get an audience as someone complaining about technical details of codecs and their implementations, than as someone complaining about the formats (which in practical terms is always going to mean the ecosystem, or really, how broad the support base is or what the user has to do in order to deal with it).
RIFF is so trivial and has such useful properties that I've done several application-specific binary formats that are RIFF with a different start atom.
RIFF itself is fine, but in the context of webp it's pointless. WebP doesn't make any use of being in a riff container. Like it still internally has its own chunk system anyway. So you end up with a single RIFF chunk for the webp file that itself then can contain multiple, non-RIFF chunks
Absolutely there is. If it works seamlessly for potentially endless end users and the burden is only on the singular you… yeah, it’s worth the extra effort on your part.
nah, life is a trade off between developer effort and the result. There is a reason we don't hand code everything in assembly anymore - it just isn't worth it.
No one is suggesting hand coding a bespoke WebP encoder. FFMPEG is an apt comparison. Using FFMPEG can be annoying, the end user benefits are enormous.
>I don't actually have this problem personally - all my apps seem to handle it fine
I heard this argument against WebP about 3 times, each time I asked people what software exactly do they use that doesn't support WebP, they told me, I checked the support (downloaded the software and opened/edited WebP file), and it did support WebP.
I deemed this "I hate WebP" just a comment bait argument in social networks.
There was a multiple year timespan where webp was being used on websites, but local software (especially image viewers/phone gallery apps) wouldn't render webp. The format's poor reputation is sadly earned.
> I deemed this "I hate WebP" just a comment bait argument in social networks.
Go try adding a webp image to a Google doc and then reconsider your position.
>Go try adding a webp image to a Google doc and then reconsider your position.
Lacking support for WebP or for other common media is a flaw of a specific service.
Many websites accept videos only in mp4 + h264 + aac audio for some reason, while there are many other video formats and codecs which could be used on the web and in general. That doesn't mean the other formats or codecs are worse or annoying.
That isn't entirely true. EVs' smaller range, and longer "refueling" time are annoyances by themselves, and compund the annoyance of not having good charging infrastructure.
OTOH, being able to charge while you are sleeping or working is pretty convenient.
I also think people don't consider how EVs are actually used when they think about longer "refueling" times. It's not like you usually bring your EV to a charger and wait for it to charge. You just plug it in at home in the evening and start every day with a charged car.
I've owned EVs for a decade, and I've never actually waited for one to charge.
If you are just commuting or driving around town, then sure. Assuming you have the setup to charge it at home. The inconvenience is when you are traveling longer distances.
> Assuming you have the setup to charge it at home
This feels like another point where people may not think about how this works in the real world. Sure, you may only have a regular plug for your car, but how long does the car stay in the garage? If you work ten hours a day, it's in the garage for 14 hours, which is plenty of time to charge the battery even if you have an hour+ commute and a slow charger.
A gas pump is somewhere on the order of ~30MW.
Even if you account for the greater efficiency of EVs we're still an order of magnitude away from equivalent charging speed.
I haven't seen much if anything saying webp itself is annoying directly, and your conclusion agrees with what I've seen. The complaining I've seen is about the tooling available (mainly from non-techies who don't care to know how to convert to another image format because, and I agree, why should they?) that once you've got a webp image file from one site the next site you try to upload it to doesn't accept them. For those of us who can convert the tooling has been there for ages, as have editors happy to load and save the format.
Though TBH I still use JPEG, PNG, or GIF, depending on use case, out of habit. The size saving for the same quality of lossy compression is not something I've found myself hankering for. It is different if you run a site that sends out millions of every image, but nothing I do is that popular and is never likely to be, and no one stuck on a really slow connection where the difference would matter to them is going to be accessing my stuff.
True, but not that rare: some maps for my fav retro games cannot be converted from PNG to WebP because of this limitation. I can slice the images but I still prefer the original appearance and layout.
Apparently Samsung Galaxy S26 Ultra has a 200MP camera with a 16,320 × 12,240 pixel resolution. So in a few years phones might be able to take pictures which can't be converted to WebP.
This is an issue with most media formats. PNG can be palletized, full-color in four or five different configurations and bit counts, or lossy. You have no idea what's actually inside of a .mkv/.mp4 either. God help you if you try to distinguish between lossy JXL and lossless HDR JXL.
A decoder can and should just do both. A MIME type/extension never really indicated what the contents are like, it just indicated the common restrictions of a file format.
Lossy/lossless is a big detail people want to know upfront. Oh, forgot webp can be animated too, that's even bigger. That gif = animation association made its way into common language.
PNGs can be animated too, APNG uses the same file extension and is rendered by browsers and other tools just fine. GIF can be animated and non-animated. Most modern GIFs are MP4s with bad file extensions. Even JPEG has been hacked into "motion jpeg" (which is a bunch of JPEG files following after each other, decoded as if it's video).
You can't even know if a .bmp is lossy or lossless because of the palletized options and the many different pixel sizes available to the format.
You can usually guess most features for some file formats most of the time, but modern all image file formats have these optional features.
The problem really boils down to WebP having no purpose to exist for any user, therefore no reason to waste time and introduce vulnerabilities for its support, especially for feature-complete software. An image format (actually not, one of those video keyframes formats that have little to do with images, let alone photos, and in its case it's 2-in-1 too with lossless), that was already outperformed by mozjpeg on its initial release as far as human eyes are concerned, and thoroughly obsoleted by jpegli..
The culprit was very often specificially Photoshop. People using old (pirated) copies of Photoshop will still be annoyed about it.
I've also encountered issues with some Linux distros not shipping webp support by default for their image viewers, for some reason, but it's been a while since I've set up a new Linux env so hopefully that's been fixed since.
I was amazed at how much better compression webp offered over jpg and png.
Using it in a web-browser 360 panorama viewer enabled pretty substantial latency and storage improvements.
close to 4x iirc.
ditto large "xray" style orthographic images of building scans generated from pointcloud laser scan data.
avif was even better compression for some cases, but seems to take a long time to generate, and less widespread browser support. Will look at jpeg-XL .. but Im guessing it will be a while until it has widespread support
It's typically 15%-30% smaller than JPEG at comparable perceptual quality. Any reduction bigger than that is just loss of quality without further compression improvement, and you could have similarly reduced file sizes by recompressing/optimizing JPEG.
In JPEG file size grows exponentially with quality, which also means that "I can't tell the difference" decrease in JPEG quality makes a huge difference in file sizes.
JPEG decoding is frequently included in systems with DSP blocks because it’s easy to add to a system that is already doing similar math for video decoding.
It’s not always used when available. It can be a lot easier and safer while being fast enough to do it on the CPU. If the operating system has an image decoder path that will handle everything for you then it might be used (Apple hardware for example) but if you have to go out of your way to implement the API, common software will favor software decoding because nobody wants to maintain code testing branches for different hardware image decode platforms.
Hardware JPEG decode isn’t as valuable on today’s hardware. CPU decode with SIMD instructions is fast and energy efficient. It’s such a negligible part of battery usage that it’s barely worth thinking about for fast modern CPUs.
Even formats like H.264 are being dropped from some hardware decode engines because it’s so easy to do on CPUs now, as can be seen even on the Raspberry Pi 5. Many software stacks will skip hardware JPEG decode even when available because it’s extra maintenance and debugging overhead for such a little gain.
Progressive decode is a feature that is good in theory but rarely used in practice. If you’re concerning yourself with power usage and memory footprints, progressive decode goes in the opposite direction. Users also don’t like progressive decode as much as developers think they will as it’s often perceived as something being broken.
I think WebP made reasonable tradeoffs for the way images are actually used and delivered.
> Even formats like H.264 are being dropped from some hardware decode engines because it’s so easy to do on CPUs now, as can be seen even on the Raspberry Pi 5
CPU decode efficiency most certainly was not the reason h.264 was dropped on the Pi
Sufficient is objective. My hardware is certainly sufficient at decoding video without performance problems, but with with CPU decode, it takes more resources and ramps up the fans. While with GPU decoding, it's near silent.
Since webp is little more than a vp8 iframe, and most SoCs already have a hardware vp8 video decoder, the additional hardware cost to decode webp is zero. Just takes a bit of firmware development effort.
And while hardware image decoders might be dubious, hardware video decoders are very much worth it.
It also lost much of its quality advantage over plain jpeg, given the improvements in jpeg encoders: the jpegli encoder (from google's jpegxl team) has improved plain jpeg encoding significantly.
Most photo/design apps don't seem to be using SOTA jpeg encoders, though, so I think webp looks better in comparisons like OP's than it actually is. You maintain all the ultra-fast decoding of jpg when you use a modern encoder, too.
People only seem to care about progressive when talking about webp. I suspect most people don't even enable progressive decoding in formats that support it.
Google aren't pushing WebP. Google Docs / Slides still don't support it.
I appreciate Google isn't a monolith, but that lack of consistency makes it really hard to shake the impression certain tribes within it are at war with each other.
It's not war, it's indifference. Why should Docs give a damn what Chrome's priorities are? The only reason they would is if there were effective leadership ensuring company-wide alignment, but there is no one filling that function.
Because if they did company wide alignment, you would kill their promotion pipeline. Want harmony? Then in Google you build your own app (see N+1 chat apps) to get that feature, get promoted and dump the project on someone else.
Strangely enough, Google wouldn't index my personal website when I was using webp. Everything in my Search Console showed up as "crawled but not indexed." I had multiple friends with SEO backgrounds check out my site, but everything looked configured correctly.
Just as with JPEG2000, I'm still not convinced the additional complexity is worth it. There seems to be a lot of immature technologies being pushed in the past few years, when IMHO the Web should've stabilised long ago on the basics. But I guess people need things to do to keep them employed... and Big Tech needs to maintain its monopolies.
The old JPG/PNG choice had a big problem: JPG handles sharp edges, including text, badly. PNG produces huge photo files. Images containing a mix of both don't work well in either format.
By contrast, when using a modern format like WEBP or AVIF, a single encoder configuration produces decent looking results across a variety of input images.
WebP is actually two completely different compression formats developed by different teams at different times for different purposes (VP8 video codec + lossless add-on by Google).
The WebP encoder just has a switch when quality=100, then use the PNG-like format in .webp, otherwise use the JPEG-like format in .webp. WebP at quality < 100 will destroy text, sometimes worse than JPEG, because VP8 can't store color at full resolution. WebP at q=100 will blow up photo sizes by orders of magnitude, similarly to PNG.
AVIF and JPEG XL actually have ability to mix-and-match blurry and sharp compression modes within a single image.
Everytime I compared AVIF to WEBP there was basically zero size or visual difference and as far as I know AVIF is slower to encode and decode. And I'm not sure yet whether .avif files can be opened natively on Windows, Linux and MacOS on the default image viewers. I think I installed some kind of plugin via the Windows Store at some point to make that work, hard to tell now.
Odd, what are you using to create your avif's? I've done a bunch of work with them and the AVIF's were almost always significantly smaller than webp at equal or better quality.
Encoding is a pain, to be sure; I ended up creating a workflow where my source would save things as PNG files (giant, but lossless) then running a avifenc (https://github.com/AOMediaCodec/libavif) to produce the avif, and trashing the PNG.
Decoding though, all browsers have support, it's great.
Author here: I'm also very much looking forward to using AVIF (and also JPEG XL), but it's another tooling question. I'm really hoping that Pixelmator Pro (now owned by Apple) will support them both soon. Photoshop (which I've recently dumped) supports WebP and AVIF, but not through the "Save for Web" or "Export As" flows. Having a nice export flow where you can easily compare compression vs. quality levels is really important to me, and I suspect to many others.
I just switched to AVIF after several years of using WebP. Main reason for me is HDR support, but the smaller encoding is nice. Just beware of lossless AVIF, that's a trap.
In GIMP, when you try to save as a "lossless" AVIF, it will add a lossy colorspace conversion step (to 8 bit YCbCr) unless you specifically specify otherwise. And lossless AVIF always loses to lossless WEBP.
When it comes to animations, is there much of a reason to use avif over webm? I suppose an avif fits into CSS and <img> without further code changes, but that's about it as far as I can think.
> I suppose an avif fits into CSS and <img> without further code changes
Which is HUGE since it allows you to embed them wherever you can embed images. I'm still mad that browser vendors didn't just allow silent looping videos in <img> tags instead of giving us these animated image formats with weirdly gimped non-keyframe compression.
https://squoosh.app/editor is a great app to compare how well an image compresses with newer formats like AVIF and WebP, compared to JPG/PNG.
It feels more practical now to have a fast loading page with large images now without too much effort. It was far too much of a burden before to have to provide fallbacks to older formats, on top of different images for different screen sizes/densities.
There are two different codecs both called "webp". There's the lossy VP8 codec, and the lossless codec that's completely different. Lossless WebP is so good that outside of image format support, there's no reason to use anything older (except for very specific kinds of repetitive images).
For the past two years, I have been exporting my images in WebP instead of JPG. If I share it online or send it by an email, I am pretty sure the other side will be able to see them.
I honestly think that all phones and even professional cameras should replace JPG with WEBP, we will have like 30% smaller photos.
The DNG format (for raw photos) allows JPEG XL compression (it used to allow only JPEG in the past). I wish some country made it mandatory for cameras to let user take photos in DNG (just like USB-C is mandatory in the EU).
I am happy that HEIC from Apple did not take off (as it was proprietary, protected by patents).
This seems to be a static website managed with Jekyll. I've never used it, but I'd be surprised if there isn't a way to automatically convert images to different formats.
I'm assuming it would take a bit longer to deploy the site and having 2 or 3 different versions of the same image would use more space, but it shouldn't be hard that hard to use AVIF, even if Pixelmator doesn't support it at the moment. It would also ensure that those with older browsers can still view the image, something that won't happen if we only have AVIF or WebP.
WebP have been in use for many years. It's good for still pictures, but its animation capabilities are very limited, because it's based on a much simplified subset of VP8 video codec.
AVIF on the contrary has great animation support. It's essentially a AV1 video without sound, but with all the benefits of <img> browser tag.
Ok, but do we _need_ WebP after all in this day and age?
Globally seen connections get faster and storage gets cheaper and we have huge amounts of tools for dealing with PNG and JPEG, so what's the deal?
Sure, use images wisely, compress them accordingly, deliver images in the right size, that's all important stuff, but you have to do that with WebP, too.
So after all those years, I don't think WebP is really solving a problem that needed solving or am I missing something?
You're asking why can't we be wasteful for wastefulness sake, even though most people access internet these days on battery powered devices using wireless radios which burn power when transferring said data?
What do you think is the impact of delivering JPEGs instead of WebPs on the battery life of an iPhone 18 Pro? Measure it and tell me, I'm curious.
And I don't want to be wasteful, but I'm wondering if we are optimizing the right things, when we are throwing established toolchains overboard to save a few kB while we probably could be saving MB in other places.
Author here: as I wrote in the piece, I've recently dumped Photoshop for Pixelmator Pro. It doesn't currently support AVIF. Photoshop does, but not in a way that makes it easy to optimize an image for web export. JPEG XL is also exciting to me, but it's not generally available across browsers. WebP is the current best image format for my use-case, but I'm hoping others supplant it soon.
>but it's not generally available across browsers.
Note that this is changing rapidly. Safari ships JXL, Chrome did a few days ago, and Firefox will in the next few days. Once this flows through to all the chromium based browsers we will see pretty much 100% support on the web.
One forum I use does not embed webp links. They show up as links, period, and it's a damn waste of my time to convert. Small is beautiful unless your forum is run by two people, not having the time to update code all the time.
Many image links that work for search engines don't work for the site and I have to download and then upload to a host to get an embeddable image link.
I love webp. I founded one of the mid 2010's "photo backup and rediscovery" startups. Webp let us offer free unlimited photo backup at the iPhone resolution of the time (iPhone 6: 8MP). We hosted billions of photos for free, and paid for it all with a sub 1% conversion rate to $5 a month for untouched jpegs. It was profitable. We had to have a few dozen auto-scaling image conversion servers for browsers that didn't support webp, but 95% of users used our apps which supported webp, so it was fine.
I'd probably go avif/jpegxl today, but webp was ahead of it's time.
The one annoying thing about WebP is that you can no longer see from the file extension whether some image is lossy or lossless.
The other annoying thing is the name, because surprisingly we use images in non-web-related contexts as well. Admittedly, PNG technically has a very similar issue, but it’s less in your face.
I use webp on my blog a lot. The software automatically converts it when I post and so on. Surprisingly small files and I've never had any trouble opening them on any platform. Big fan.
Meanwhile, JPEG-LI is literally JPEG, just with different rules for how the image is decoded in order to support higher color resolution. (And different rules during encoding to allocate bits differently, usually boosting the bitrate of luma and cutting the bitrate of chroma)
So as every time I read something decrying how webp is allegedly "annoying", the conclusion is that the problem was never about webp itself but the tooling and ecosystem to handle it
Does Windows already display WebP files in File Explorer? :-|
It has done for some years
Yes. https://imgur.com/a/lRSM128
Windows 10's support isn't out of the box. You need to install an explorer extension, and even then it's a bit shaky.
I personally avoid webp because of the tooling/compatibility issues.
Windows 10 support went EOL one year ago. It is an archaic operating system, so no doubt, it does not support modern technology out-of-the-box. Nevertheless, it can be modified to add such support with trivial effort.
> It is an archaic operating system
Do you have a reliable source you can share which supports that claim?
Per Microsoft: https://learn.microsoft.com/en-us/lifecycle/products/windows...
Windows 10 is over 10 years old now
How is that "archaic"?
> Windows 10 support went EOL
https://www.microsoft.com/en-us/windows/end-of-support
We must have extremely different definitions of the word "archaic".
Windows 10 support is out of the box, I explicitly checked that in one of "I hate WebP" argument
>I've opened both .webp and .avif on Windows 10 22H2 in Standard MS "Photos", "MS Paint", "Paint 3D" applications before posting the previous message.
>Just tested in older Windows 10 21H2, and yes, in this version Paint doens't open webp
Firefox actually silently and automatically converts images to webp in some cases when you Save As them, with no option to revert to the format you see in the DOM. It’s fucking infuriating. I hate webp because the support is so spotty.
I don't think that's firefox doing it? I'd guess it's some CDNs doing the conversion. Or the URL says .jpg but when you look at the mimetype sent by the server it's actually webp. Extentions are meaningless for browsers.
I highly doubt that is what's happening. More likely the server is serving a webp under a .png filename or something.
I have observed the behavior you suspect many times.
It's not Firefox, it's the server. Edit and resend the request with header "Accept: image/jpeg" only and you'll most likely get a JPEG file.
Does it actually request the image that it already downloaded again to save it to a file? Seems rather silly?
No, the server is just sending the file named 'foo.jpg', but encoded as a webp with webp mime type, so when you save the file it defaults to the webp extension cause it ends up treating the filename as a blob of text without an expected extension for the file type.
No, this is not what’s happening. Or at least not the phenomenon I am discussing.
That seems more likely. I still hate webp.
This would cause the downloaded file to have incorrect file extension because such services don't configure the Content-Disposition header properly, and you still may have lots of improperly named files unless you realize that the file content doesn't match its extension.
Annoyingly, this doesn't work for a whole lot of websites that insist on serving webp, they just ignore the header. Some of them have bespoke workarounds like adding ?format=original on fandom wikis, with some the server will just never serve you anything other than webp.
> the tooling and ecosystem to handle it
That’s the whole point, though. If the tools I use don’t handle it properly, it’s annoying. Saying it’s an ecosystem problem doesn’t change that.
How long has it been now? And from what I’ve seen, even Google’s own stuff doesn’t always handle it. That’s not helping their case.
Well, that's a problem with the tools you are using. Tools to work with webp have existed for a long time.
To not be annoying the tools don't have to just exist somewhere, they need to be ubiquitous. For example, If I'm looking to upload an image as an avatar on a website, will webp be supported? It's unlikely, even if the site itself might ultimately serve up a webp file. So then I'd have to use a tool to convert it to a more ubiquitous format before uploading it, likely doing a bunch of lossy conversion along the way. That's annoying.
Yeah it's purely the fault of the tens of thousands of application devs that have been too stupid to recognize the obvious and immense benefits of webp over existing widely adopted formats /s
When said application charges an exorbitant monthly fee, and is owned by a multibillion company, yeah it *is* pretty ridiculous.
Sure but there are also so many small open source projects that work with images too.
Is there a real distinction? It can be a great format, but if actually using it sucks then in practice it's a pain to use/encounter. (I don't actually have this problem personally - all my apps seem to handle it fine - but the argument seems reasonable.)
Yes, it's important to distinguish annoyances of the codec from annoyances of the ecosystem.
Ecosystem being slow to adopt it is something that can be fixed or improved, but also more importantly (given jpegxl & avif comparisons) are things that will impact any new image format.
Meanwhile annoyances of the codec tend to be things that are dramatically harder to deal with. Like HEIC being a license minefield and also slow as shit. Or that many of these newer image codecs do not have ways to work with them in a memory efficient manner like jpeg does (see eg libjpeg-turbo's sample size & skip scanline options). Or WebP insisted on being in a RIFF container for... uh... absolutely no fucking reason whatsoever afaict. Fortunately RIFF is so trivial that this overhead doesn't actually matter in practice, but then HEIC & AVIF dials up the annoying container bullshit to 11 thanks to their video heritage with ISOBMFF
Perhaps it's a matter of who hits the pain point? Ugly specs make annoyed devs, licensing problems make distributors unhappy, and ecosystem issues leave users unimpressed. (With some spillover between categories, of course.)
> Like HEIC being a license minefield and also slow as shit.
How much slower? I'm finding very conflicting numbers.
But on the timescale of "wow this still doesn't support webp" those patents will solve themselves soon.
hardware-decoded HEIC is around 10x slower than JPEG.
software-decoded HEIC is around 100x slower than JPEG.
WebP is something like 20-50% slower than JPEG, so still solidly an order of magnitude faster than best case hardware-accelerated HEIC decoding.
How slow are we talking though? 10x slower than instant and not noticeable for the average use case? Dog slow and everyone will always notice?
well that depends on the size of the image. But a modern cell phone is shooting 50mp+, and at that size you're talking 50-200ms for a jpeg vs. a couple seconds for HEIC. Which is borderline instant-feeling vs. extremely not instant.
HEVC intra is definitely not 10-20x slower than decoding VP8 intra, so something is way off with your numbers. That's on the order of comparing HM at -O0 against an actual VP8 decoder.
It seems much harder to get an audience as someone complaining about technical details of codecs and their implementations, than as someone complaining about the formats (which in practical terms is always going to mean the ecosystem, or really, how broad the support base is or what the user has to do in order to deal with it).
RIFF is so trivial and has such useful properties that I've done several application-specific binary formats that are RIFF with a different start atom.
RIFF itself is fine, but in the context of webp it's pointless. WebP doesn't make any use of being in a riff container. Like it still internally has its own chunk system anyway. So you end up with a single RIFF chunk for the webp file that itself then can contain multiple, non-RIFF chunks
Absolutely there is. If it works seamlessly for potentially endless end users and the burden is only on the singular you… yeah, it’s worth the extra effort on your part.
nah, life is a trade off between developer effort and the result. There is a reason we don't hand code everything in assembly anymore - it just isn't worth it.
cough FFMPEG, cryptography…
So no actually we very much do, because sometimes it is worth it.
sure, but we don't hand-code everything.
No one is suggesting hand coding a bespoke WebP encoder. FFMPEG is an apt comparison. Using FFMPEG can be annoying, the end user benefits are enormous.
well yes, my point was its a trade off...
It matters. The ecosystem by itself could be fixable. But a bad ecosystem could also be a symptom of a bad standard, for example IPv6.
>I don't actually have this problem personally - all my apps seem to handle it fine
I heard this argument against WebP about 3 times, each time I asked people what software exactly do they use that doesn't support WebP, they told me, I checked the support (downloaded the software and opened/edited WebP file), and it did support WebP.
I deemed this "I hate WebP" just a comment bait argument in social networks.
There was a multiple year timespan where webp was being used on websites, but local software (especially image viewers/phone gallery apps) wouldn't render webp. The format's poor reputation is sadly earned.
> I deemed this "I hate WebP" just a comment bait argument in social networks.
Go try adding a webp image to a Google doc and then reconsider your position.
>Go try adding a webp image to a Google doc and then reconsider your position.
Lacking support for WebP or for other common media is a flaw of a specific service.
Many websites accept videos only in mp4 + h264 + aac audio for some reason, while there are many other video formats and codecs which could be used on the web and in general. That doesn't mean the other formats or codecs are worse or annoying.
> the conclusion is that the problem was never about webp itself but the tooling and ecosystem to handle it
That is true in life.
EVs aren’t annoying, the charging infrastructure is.
Etc
That isn't entirely true. EVs' smaller range, and longer "refueling" time are annoyances by themselves, and compund the annoyance of not having good charging infrastructure.
OTOH, being able to charge while you are sleeping or working is pretty convenient.
BYD flash charging is as fast as a gas pump.
Alternatively, my buddies EV does 700km to a charge. I’m not driving 7 hours straight without a good break.
I also think people don't consider how EVs are actually used when they think about longer "refueling" times. It's not like you usually bring your EV to a charger and wait for it to charge. You just plug it in at home in the evening and start every day with a charged car.
I've owned EVs for a decade, and I've never actually waited for one to charge.
If you are just commuting or driving around town, then sure. Assuming you have the setup to charge it at home. The inconvenience is when you are traveling longer distances.
> Assuming you have the setup to charge it at home
This feels like another point where people may not think about how this works in the real world. Sure, you may only have a regular plug for your car, but how long does the car stay in the garage? If you work ten hours a day, it's in the garage for 14 hours, which is plenty of time to charge the battery even if you have an hour+ commute and a slow charger.
IME pro-EV people will say "L1 is all you need" but then motte-and-bailey and insist having an L2 is essential for cold winters...
We have snow half the year. The car goes about 20% less far. That's all.
Less about range (though mine is ~30% hit) and more about a 120V socket not being able to heat the battery to charge effectively in sub-zero temps.
Hm, yeah. Mine is in a garage.
Not everyone has a garage with power at all to park their car in.
For a while, I charged my car with a long cable coming out of my second-story flat window
That sounds pretty annoying to me. And probably violates HOA covenants or apartment rules in a lot of places.
After owning an EV for a year I have only truly needed to charge at a fast charger on two trips.
Both times I absolutely did notice the slow "refueling" times, but for 95% of my driving "around town" it is _so_ nice.
A gas pump is somewhere on the order of ~30MW. Even if you account for the greater efficiency of EVs we're still an order of magnitude away from equivalent charging speed.
The theoretical amount of energy transferred is irrelevant. All that matters is how long it takes to ”refill” the car.
Even going as fast as I can on a small car (45l tank), it takes about 6 minutes.
BYD flash charging is very close to that.
I haven't seen much if anything saying webp itself is annoying directly, and your conclusion agrees with what I've seen. The complaining I've seen is about the tooling available (mainly from non-techies who don't care to know how to convert to another image format because, and I agree, why should they?) that once you've got a webp image file from one site the next site you try to upload it to doesn't accept them. For those of us who can convert the tooling has been there for ages, as have editors happy to load and save the format.
Though TBH I still use JPEG, PNG, or GIF, depending on use case, out of habit. The size saving for the same quality of lossy compression is not something I've found myself hankering for. It is different if you run a site that sends out millions of every image, but nothing I do is that popular and is never likely to be, and no one stuck on a really slow connection where the difference would matter to them is going to be accessing my stuff.
It's still annoying that if you set quality anywhere below 100, you get half-resolution color (VP8 only has 4:2:0 chroma subsampling).
The fact that there is a size limit (16,383 x 16,383 pixels) is still annoying for some (rare) use cases.
True, but not that rare: some maps for my fav retro games cannot be converted from PNG to WebP because of this limitation. I can slice the images but I still prefer the original appearance and layout.
Apparently Samsung Galaxy S26 Ultra has a 200MP camera with a 16,320 × 12,240 pixel resolution. So in a few years phones might be able to take pictures which can't be converted to WebP.
It's annoying how the format itself, or should I say just the file extension, doesn't make it clear whether or not you have lossy compression.
This is an issue with most media formats. PNG can be palletized, full-color in four or five different configurations and bit counts, or lossy. You have no idea what's actually inside of a .mkv/.mp4 either. God help you if you try to distinguish between lossy JXL and lossless HDR JXL.
A decoder can and should just do both. A MIME type/extension never really indicated what the contents are like, it just indicated the common restrictions of a file format.
Lossy/lossless is a big detail people want to know upfront. Oh, forgot webp can be animated too, that's even bigger. That gif = animation association made its way into common language.
PNGs can be animated too, APNG uses the same file extension and is rendered by browsers and other tools just fine. GIF can be animated and non-animated. Most modern GIFs are MP4s with bad file extensions. Even JPEG has been hacked into "motion jpeg" (which is a bunch of JPEG files following after each other, decoded as if it's video).
You can't even know if a .bmp is lossy or lossless because of the palletized options and the many different pixel sizes available to the format.
You can usually guess most features for some file formats most of the time, but modern all image file formats have these optional features.
Nobody uses APNG though. Maybe they would if it had a distinct file extension. There is non-animated GIF, but it's super rare because why.
The problem really boils down to WebP having no purpose to exist for any user, therefore no reason to waste time and introduce vulnerabilities for its support, especially for feature-complete software. An image format (actually not, one of those video keyframes formats that have little to do with images, let alone photos, and in its case it's 2-in-1 too with lossless), that was already outperformed by mozjpeg on its initial release as far as human eyes are concerned, and thoroughly obsoleted by jpegli..
It has transparency support, unlike JPEG.
The culprit was very often specificially Photoshop. People using old (pirated) copies of Photoshop will still be annoyed about it.
I've also encountered issues with some Linux distros not shipping webp support by default for their image viewers, for some reason, but it's been a while since I've set up a new Linux env so hopefully that's been fixed since.
And only some software. All my Linux software supports it and have been for ages.
I was amazed at how much better compression webp offered over jpg and png.
Using it in a web-browser 360 panorama viewer enabled pretty substantial latency and storage improvements.
close to 4x iirc.
ditto large "xray" style orthographic images of building scans generated from pointcloud laser scan data.
avif was even better compression for some cases, but seems to take a long time to generate, and less widespread browser support. Will look at jpeg-XL .. but Im guessing it will be a while until it has widespread support
It's typically 15%-30% smaller than JPEG at comparable perceptual quality. Any reduction bigger than that is just loss of quality without further compression improvement, and you could have similarly reduced file sizes by recompressing/optimizing JPEG.
In JPEG file size grows exponentially with quality, which also means that "I can't tell the difference" decrease in JPEG quality makes a huge difference in file sizes.
Webp does not have hardware decode and does not support progressive.
I speculate the asymmetric push is a case of it solving Google’s problem (bandwidth cost) but not the end user’s problems (battery and latency).
Is hardware decoding even commonly used for still image codecs?
Only for HEIC realistically, and that only still causes it to struggle to match jpeg or webp performance anyway
HEIC is a container, not a codec. You can put an avif in there if you want to.
True, but almost everybody that says HEIC these days means HEIF, in my experience.
HEIF is a container not a codec. HEIC is HEIF + HEVC.
AVIF and HEIC both use HEIF
You have that backwards. HEIF is the container format. HEIC is a HEIF file using HEVC.
JPEG decoding is frequently included in systems with DSP blocks because it’s easy to add to a system that is already doing similar math for video decoding.
It’s not always used when available. It can be a lot easier and safer while being fast enough to do it on the CPU. If the operating system has an image decoder path that will handle everything for you then it might be used (Apple hardware for example) but if you have to go out of your way to implement the API, common software will favor software decoding because nobody wants to maintain code testing branches for different hardware image decode platforms.
Hardware JPEG decode isn’t as valuable on today’s hardware. CPU decode with SIMD instructions is fast and energy efficient. It’s such a negligible part of battery usage that it’s barely worth thinking about for fast modern CPUs.
Even formats like H.264 are being dropped from some hardware decode engines because it’s so easy to do on CPUs now, as can be seen even on the Raspberry Pi 5. Many software stacks will skip hardware JPEG decode even when available because it’s extra maintenance and debugging overhead for such a little gain.
Progressive decode is a feature that is good in theory but rarely used in practice. If you’re concerning yourself with power usage and memory footprints, progressive decode goes in the opposite direction. Users also don’t like progressive decode as much as developers think they will as it’s often perceived as something being broken.
I think WebP made reasonable tradeoffs for the way images are actually used and delivered.
> Even formats like H.264 are being dropped from some hardware decode engines because it’s so easy to do on CPUs now, as can be seen even on the Raspberry Pi 5
CPU decode efficiency most certainly was not the reason h.264 was dropped on the Pi
Dropping it was an option because CPU decode was sufficient.
Sufficient is objective. My hardware is certainly sufficient at decoding video without performance problems, but with with CPU decode, it takes more resources and ramps up the fans. While with GPU decoding, it's near silent.
Then why do they put it on the phones? surely manufacturers would love to cut the part?
Since webp is little more than a vp8 iframe, and most SoCs already have a hardware vp8 video decoder, the additional hardware cost to decode webp is zero. Just takes a bit of firmware development effort.
And while hardware image decoders might be dubious, hardware video decoders are very much worth it.
It also lost much of its quality advantage over plain jpeg, given the improvements in jpeg encoders: the jpegli encoder (from google's jpegxl team) has improved plain jpeg encoding significantly.
Most photo/design apps don't seem to be using SOTA jpeg encoders, though, so I think webp looks better in comparisons like OP's than it actually is. You maintain all the ultra-fast decoding of jpg when you use a modern encoder, too.
Thanks for the reference.
People only seem to care about progressive when talking about webp. I suspect most people don't even enable progressive decoding in formats that support it.
I recently went through a format selection and did.
Are you arguing more people should turn it on? Or that it would be bad to?
i'm arguing that in real life nobody cares about it. I don't think it matters.
Btw, even Google doesn't support webp for many of its products, like Docs/Slides.
Google aren't pushing WebP. Google Docs / Slides still don't support it.
I appreciate Google isn't a monolith, but that lack of consistency makes it really hard to shake the impression certain tribes within it are at war with each other.
It's not war, it's indifference. Why should Docs give a damn what Chrome's priorities are? The only reason they would is if there were effective leadership ensuring company-wide alignment, but there is no one filling that function.
Because if they did company wide alignment, you would kill their promotion pipeline. Want harmony? Then in Google you build your own app (see N+1 chat apps) to get that feature, get promoted and dump the project on someone else.
Yeah, the classic image still holds true.
https://www.globalnerdy.com/2011/07/03/org-charts-of-the-big...
Ah, I've never seen that but it's great!
This is actually a good counter argument for 'Google is pushing X'. If they were pushing X, they'd make all their apps fall in line.
Contrast this to, say, Apple - which when decides to push something, they go all in. And that's an example of top-down decision making.
Strangely enough, Google wouldn't index my personal website when I was using webp. Everything in my Search Console showed up as "crawled but not indexed." I had multiple friends with SEO backgrounds check out my site, but everything looked configured correctly.
Switching all my images back to jpg solved it
I think since the beginning of google I've seen a gif in image search maybe 5 times in total.
Just as with JPEG2000, I'm still not convinced the additional complexity is worth it. There seems to be a lot of immature technologies being pushed in the past few years, when IMHO the Web should've stabilised long ago on the basics. But I guess people need things to do to keep them employed... and Big Tech needs to maintain its monopolies.
The old JPG/PNG choice had a big problem: JPG handles sharp edges, including text, badly. PNG produces huge photo files. Images containing a mix of both don't work well in either format.
By contrast, when using a modern format like WEBP or AVIF, a single encoder configuration produces decent looking results across a variety of input images.
How is it "a single encoder configuration"? WEBP has separate lossy and lossless compression modes and simply gives both the same filename extension.
i thought their point was that even in lossy mode, it works acceptable for both.
WebP is actually two completely different compression formats developed by different teams at different times for different purposes (VP8 video codec + lossless add-on by Google).
The WebP encoder just has a switch when quality=100, then use the PNG-like format in .webp, otherwise use the JPEG-like format in .webp. WebP at quality < 100 will destroy text, sometimes worse than JPEG, because VP8 can't store color at full resolution. WebP at q=100 will blow up photo sizes by orders of magnitude, similarly to PNG.
AVIF and JPEG XL actually have ability to mix-and-match blurry and sharp compression modes within a single image.
JPEG has a lossless mode too, but it's also very rarely used: https://en.wikipedia.org/wiki/Lossless_JPEG
"Lossless JPEG" is basically in name only, since it has nothing in common with regular JPEG.
At what year would you say the web should have stabilized on the basics?
As in JPEG, GIF, and PNG? Early 2000s. Maybe with a subset of SWF as a (animated)/vector format instead of horribly bloated SVG.
Avif.
Especially for animated images. Comparing webp or avif sizes to gif is easily a factor of five to ten when animated.
Since all modern browsers support AVIF, I'd skip WEBP and just use AVIF (possibly with a fallback for JPG/PNG).
Everytime I compared AVIF to WEBP there was basically zero size or visual difference and as far as I know AVIF is slower to encode and decode. And I'm not sure yet whether .avif files can be opened natively on Windows, Linux and MacOS on the default image viewers. I think I installed some kind of plugin via the Windows Store at some point to make that work, hard to tell now.
Odd, what are you using to create your avif's? I've done a bunch of work with them and the AVIF's were almost always significantly smaller than webp at equal or better quality.
Encoding is a pain, to be sure; I ended up creating a workflow where my source would save things as PNG files (giant, but lossless) then running a avifenc (https://github.com/AOMediaCodec/libavif) to produce the avif, and trashing the PNG.
Decoding though, all browsers have support, it's great.
> and trashing the PNG.
I don't delete my original source images, in case if I want to change the encoder parameters later, or if a newer encoder version improves quality.
Author here: I'm also very much looking forward to using AVIF (and also JPEG XL), but it's another tooling question. I'm really hoping that Pixelmator Pro (now owned by Apple) will support them both soon. Photoshop (which I've recently dumped) supports WebP and AVIF, but not through the "Save for Web" or "Export As" flows. Having a nice export flow where you can easily compare compression vs. quality levels is really important to me, and I suspect to many others.
Google is no longer actively working or supporting JPEG XL.
Are you sure? They just blogged about supporting it in Chrome with their Google developed jxl implmention in Rust.
They're bringing it back. Chrome 155 onwards will support it.
https://developer.chrome.com/blog/jpeg-xl-in-chrome
Besides VMAF Netflix also released an image comparing framework back in 2020. Might be worth a look: https://netflixtechblog.com/avif-for-next-generation-image-c...
I just switched to AVIF after several years of using WebP. Main reason for me is HDR support, but the smaller encoding is nice. Just beware of lossless AVIF, that's a trap.
In GIMP, when you try to save as a "lossless" AVIF, it will add a lossy colorspace conversion step (to 8 bit YCbCr) unless you specifically specify otherwise. And lossless AVIF always loses to lossless WEBP.
When it comes to animations, is there much of a reason to use avif over webm? I suppose an avif fits into CSS and <img> without further code changes, but that's about it as far as I can think.
An AVIF and a WebM + AV1 is basically identical file-size wise, but you can zoom in on an AVIF so for actual animated images it wins on that front.
i think alpha channel is a reason, but i agree, just use webm
> I suppose an avif fits into CSS and <img> without further code changes
Which is HUGE since it allows you to embed them wherever you can embed images. I'm still mad that browser vendors didn't just allow silent looping videos in <img> tags instead of giving us these animated image formats with weirdly gimped non-keyframe compression.
https://squoosh.app/editor is a great app to compare how well an image compresses with newer formats like AVIF and WebP, compared to JPG/PNG.
It feels more practical now to have a fast loading page with large images now without too much effort. It was far too much of a burden before to have to provide fallbacks to older formats, on top of different images for different screen sizes/densities.
There are two different codecs both called "webp". There's the lossy VP8 codec, and the lossless codec that's completely different. Lossless WebP is so good that outside of image format support, there's no reason to use anything older (except for very specific kinds of repetitive images).
Throwback to the spacer gif era where we would slice a photoshop design and make it fit in HTML tables
I remember moving on to PNG when that was implemented in most browsers and suddenly you could do gradients that end in transparency...
Ah, the old ‘filter for IE’ [1] to support PNG transparency!
[1] https://stackoverflow.com/questions/1852467/alpha-transparen...
Or to make rounded corners, buttons...
For the past two years, I have been exporting my images in WebP instead of JPG. If I share it online or send it by an email, I am pretty sure the other side will be able to see them.
I honestly think that all phones and even professional cameras should replace JPG with WEBP, we will have like 30% smaller photos.
The DNG format (for raw photos) allows JPEG XL compression (it used to allow only JPEG in the past). I wish some country made it mandatory for cameras to let user take photos in DNG (just like USB-C is mandatory in the EU).
I am happy that HEIC from Apple did not take off (as it was proprietary, protected by patents).
> I honestly think that all phones and even professional cameras should replace JPG with WEBP, we will have like 30% smaller photos.
> I am happy that HEIC from Apple did not take off (as it was proprietary, protected by patents).
Canon, Nikon, Sony, Panasonic, and Fujifilm cameras all shoot HEIF these days.
Does this person know you can just... ship multiple formats? Just add avif
Other than their tool of choice not supporting it..?
> I’m wondering if/when newer standards like ... AVIF will be supported by Pixelmator Pro.
This seems to be a static website managed with Jekyll. I've never used it, but I'd be surprised if there isn't a way to automatically convert images to different formats.
I'm assuming it would take a bit longer to deploy the site and having 2 or 3 different versions of the same image would use more space, but it shouldn't be hard that hard to use AVIF, even if Pixelmator doesn't support it at the moment. It would also ensure that those with older browsers can still view the image, something that won't happen if we only have AVIF or WebP.
They shouldn't be manually exporting web formats
WebP have been in use for many years. It's good for still pictures, but its animation capabilities are very limited, because it's based on a much simplified subset of VP8 video codec.
AVIF on the contrary has great animation support. It's essentially a AV1 video without sound, but with all the benefits of <img> browser tag.
https://files.catbox.moe/blnad2.avif (334 KB, 35 seconds, 352×352 18 fps)
Ok, but do we _need_ WebP after all in this day and age?
Globally seen connections get faster and storage gets cheaper and we have huge amounts of tools for dealing with PNG and JPEG, so what's the deal?
Sure, use images wisely, compress them accordingly, deliver images in the right size, that's all important stuff, but you have to do that with WebP, too.
So after all those years, I don't think WebP is really solving a problem that needed solving or am I missing something?
You're asking why can't we be wasteful for wastefulness sake, even though most people access internet these days on battery powered devices using wireless radios which burn power when transferring said data?
What do you think is the impact of delivering JPEGs instead of WebPs on the battery life of an iPhone 18 Pro? Measure it and tell me, I'm curious.
And I don't want to be wasteful, but I'm wondering if we are optimizing the right things, when we are throwing established toolchains overboard to save a few kB while we probably could be saving MB in other places.
Why? Just skip webp altogether, an annoying footnote that caused more issues than it solved.
Go straight to jpeg xl and/or avif when the they are mature.
Author here: as I wrote in the piece, I've recently dumped Photoshop for Pixelmator Pro. It doesn't currently support AVIF. Photoshop does, but not in a way that makes it easy to optimize an image for web export. JPEG XL is also exciting to me, but it's not generally available across browsers. WebP is the current best image format for my use-case, but I'm hoping others supplant it soon.
>but it's not generally available across browsers.
Note that this is changing rapidly. Safari ships JXL, Chrome did a few days ago, and Firefox will in the next few days. Once this flows through to all the chromium based browsers we will see pretty much 100% support on the web.
One forum I use does not embed webp links. They show up as links, period, and it's a damn waste of my time to convert. Small is beautiful unless your forum is run by two people, not having the time to update code all the time.
Many image links that work for search engines don't work for the site and I have to download and then upload to a host to get an embeddable image link.
X doesn't support animated webp, slightly annoying.
XPM works just fine though.
I love webp. I founded one of the mid 2010's "photo backup and rediscovery" startups. Webp let us offer free unlimited photo backup at the iPhone resolution of the time (iPhone 6: 8MP). We hosted billions of photos for free, and paid for it all with a sub 1% conversion rate to $5 a month for untouched jpegs. It was profitable. We had to have a few dozen auto-scaling image conversion servers for browsers that didn't support webp, but 95% of users used our apps which supported webp, so it was fine.
I'd probably go avif/jpegxl today, but webp was ahead of it's time.
Yet, Gmail can’t handle transparent .webp in their email previews
Annoyingly Google voice doesn't support it at all, either. I've installed a firefox extension[0] that saves any image as .JPG,.PNG, or .WEBP
[0] https://addons.mozilla.org/en-US/firefox/addon/siat/
The one annoying thing about WebP is that you can no longer see from the file extension whether some image is lossy or lossless.
The other annoying thing is the name, because surprisingly we use images in non-web-related contexts as well. Admittedly, PNG technically has a very similar issue, but it’s less in your face.
All this, and also PNG and JPEG both sound cool when you say them out loud. Web-pee on the other hand...
I use webp on my blog a lot. The software automatically converts it when I post and so on. Surprisingly small files and I've never had any trouble opening them on any platform. Big fan.
Let not forget you can save a canvas as webP with toBlob.
Don't use webp/avif if users from your app likes to paste long screenshots.
I mean really, really long. Hard lessons learned
mozjpeg turbo, nananananana :D works, small, great quality, nobody cares about the rest
Meanwhile, JPEG-LI is literally JPEG, just with different rules for how the image is decoded in order to support higher color resolution. (And different rules during encoding to allocate bits differently, usually boosting the bitrate of luma and cutting the bitrate of chroma)