Why JPEGs still rule the web (2024)

> JPEG-XL seemed like the next logical step until Google took their toys and killed it despite already having the support in Chrome, which pretty much makes it dead in the water (don't you just love monopolies making decisions for you?)

It's worth noting that Firefox is willing to adopt JPEG-XL[1] as soon as the rust implementation[2] is mature And that rust impl is a direct port from the reference C++ implementation[3]. Mac OS and Safari already support JPEG-XL [4]. And recently Windows picked up JPEG-XL support. The only blockers at this point are Firefox, Chromium, and Android. If/when Firefox adopts JPEG-XL, we'll probably see google follow suit if only out of pressure from downstream Chromium platforms wanting to adopt it to maintain parity.

So really if you want to see JPEG-XL get adopted, go throw some engineering hours at the rust implementation [2] to help get it up to feature parity with the reference impl.

-----

1. https://github.com/mozilla/standards-positions/pull/1064

2. https://github.com/libjxl/jxl-rs

3. https://github.com/libjxl/libjxl

4. https://www.theregister.com/2023/06/07/apple_safari_jpeg_xl/

5. https://www.windowslatest.com/2025/03/05/turn-on-jpeg-xl-jxl...

> HEIC is good, as long as you pinky promise to never ever leave Apple's ecosystem, ie HEIC sucks.

HEIC was developed by the MPEG folks and is an ISO standard, ISO/IEC 23008-12:2022:

* https://www.iso.org/standard/83650.html

* https://en.wikipedia.org/wiki/High_Efficiency_Image_File_For...

An HEIC image is generally a still frame from ITU-T H.265† (HEVC):

* https://www.geeky-gadgets.com/heif-avc-h-264-h-265-heic-and-...

OS support includes Windows 10 v1083, Android 10+, Ubuntu 20.04, Debian 10, Fedora 36. Lots of cameras and smartphones support it as well.

There's nothing Apple-specific about it. Apple went through the process of licensing H.265, so they got HEIC 'for free' and use it as the default image format because over JPEG it supports: HDR, >8-bit colour, etc.

†Like WebP was similar to an image/frame from a VP8 video.

> Just as there is a clear winner for video - av1 - there seems to be nothing in the way of "this is clearly the future, at least for the next few years" when it comes to encoding images.

Say what? A random scan across the internet will reveal more videos in MP4 and H.264 format than av1. Perhaps streaming services have switched, but that is not what regular consumers usually use to make and store movies.

From what I've seen WebP is probably the strongest contender for a JPEG replacement. It's pretty common in the indie game scene for example to re-encode a JPEG game to WebP for better image quality and often a significant (25% or more) savings on installer size. Support is coming, albeit somewhat slowly. It was pretty bad in Ubuntu 22, but several apps have added support in Ubuntu 24. Windows 11 supports WebP in Photos and Paint for another example.

Normal people use jpeg. It's good enough, much like mpeg-2 was good enough for DVDs. Compatibility always beats storage efficiency.

Photography nerds will religiously store raw images that they then never touch. They're like compliance records.

> How in the world do people store images / photos nowadays?

Well, as JPEGs? Why not? Quality is just fine if you don't touch the quality slider in Photoshop or other software.

For "more" there's still lossless camera RAW formats and large image formats like PSD and whatnot.

JPEG is just fine.

For my extensive collection of photography, I export to JPEG-XL and then convert to JPEG for use online. Most online services, like Flickr, Instagram, et al don't support JPEG-XL, but there's almost no quality loss converting from JPEG-XL to JPEG vs exporting to JPEG directly from your digital asset management system, and storing locally in JPEG-XL works very well. Almost all desktop tools I use support JPEG-XL natively already, conversely almost nothing support WEBP.

People often forget that PNG images can be compressed in a lossy manner to keep the filesize down, not quite as well as jpegs but still quite substantially.

https://pngmini.com/lossypng.html

https://pngquant.org/

https://css-ig.net/pinga

Tiff if you want to archive them and they started as raw or tiff, jpeg for everything else. If the file is already jpeg, there is no point in covering it to a new better quality format, the quality won't get better than it already is.

It may be obsolete, but it is ubiquitous. I care less about cutting edge tech than I do about the probability of being able to open it in 20+ years. Storage is cheap.

Presentation is a different matter and often should be a different format than whatever your store the original files as.

AV1 is not the clear winner for video. Currently-existing encoders are worse than x265 for high-bitrate encodes.

> How in the world do people store images / photos nowadays?

I had some high resolution graphic works in TIFF (BMP + LZW). To save space, I archived them using JPEG-2000 (lossless mode), using the J2k Photoshop plug-in ( https://www.fnord.com/ ). Saved tons of GBs. It has wide multi-platform support and is a recognized archival format, so its longevity is guaranteed for some time on our digital platforms. Recently explored using HEIF or even JPEG-XL for these but these formats still don't handle CMYK colour modes well.

>are nigh-unworkable on desktops, support is very spotty

I use .webp often and I don't understand this. At least on Windows 10 I can go to a .webp and see a preview and double-click and it opens in my image editor. Is it not like this elsewhere?

I recognize it as beating a dead horse now, but JPEG XL did what was needed to be actually adopted. AVIF has not been widely adopted given the difficulty of a leap to a new format in general and the computational cost of encoding AVIF specifically.

One of JPEG XL's best ideas was incorporating Brunsli, lossless recompression for existing JPEGs (like Dropbox's Lepton which I think might've been talked about earlier). It's not as much of a space win as a whole new format, but it's computationally cheap and much easier to just roll out today. There was even an idea of supporting it as a Content-Encoding, so a right-click and save would get you an OG .jpg avoiding the whole "what the heck is a WebP?" problem. (You might still be able to do something like this in a ServiceWorker, but capped at wasm speeds of course.) Combine it with improved JPEG encoders like mozjpeg and you're not in a terrible place. There's also work that could potentially be done with deblocking/debanding/deringing in decoders to stretch the old approach even further.

And JXL's other modes also had their advantages. VarDCT was still faster than libaom AVIF, and was reasonable in its own way (AVIFs look smoother, JXL tended more to preserve traces of low-contrast detail). There was a progressive mode, which made less sense in AVIF because it was a format for video keyframes first. The lossless mode was the evolution of FUIF and put up good numbers.

At this point I have no particular predictions. JPEG never stopped being usable despite a series of more technically sophisticated successors. (MP3 too, though its successors seemed to get better adoption.) Perhaps it means things continue not to change for a while, or at least that I needn't rush to move to $other_format or get left behind. Doesn't mean I don't complain about the situation in comments on the Internet, though.

> So what's left? I have a whole bunch of .HEIC photos and I'd really like if Windows Explorer didn't freeze for literal minutes when I open a folder with them.

Yea, how is this still the case in 2025?

My family has a mix of Apple and Samsung devices and they move/backup their pictures to their Windows machines whenever they run out of space but once they move them, they can't easily view or browse them.

I had to download a 3rd party app and teach them to view them from there.

I store Raw + PSD with edits/history + whatever edited output format(s) I used.

> JPEG-XL seemed like the next logical step until Google took their toys and killed it despite already having the support in Chrome, which pretty much makes it dead in the water (don't you just love monopolies making decisions for you?)

I've done several tests where I lowered the quality settings (and thus, the resulting file size) of JPEG-XL and AVIF encoders over a variety of images. In almost every image, JPEG-XL subjective quality fell faster than AVIF, which seemed mostly OK for web use at similar file sizes. Due to that last fact, I concede that Chrome's choice to drop JPEG-XL support is correct. If things change (JPEG-XL becomes more efficient at low file sizes, gains Chrome support), I have lossless PNG originals to re-encode from.

I've done a few shootouts at various times in the last 10 years. I finally decided WebP was good for the web maybe two years ago, that is, I have 'set it or forget it' settings and get a good quality/size result consistently. (JPEG has the problem that you really need to turn the knob yourself since a quality level good for one image may not be good for another one)

I don't like AVIF, at least not for photos I want to share. I think AVIF is great for "a huge splash image for a web page that nobody is going to look at closely" but if you want something that looks like a pro photo I don't think it's better than WebP. People point out this example as "AVIF is great"

https://jakearchibald.com/2020/avif-has-landed/demos/compare...

but I think it badly mangles the reflection on the left wing of the car and... it's those reflections that make sports cars look sexy. (I'll grant that the 'acceptable' JPEG has obvious artifacts whereas the 'acceptable' AVIF replaced a sexy reflection with a plausible but slighly dull replacement)

At least there's JPEG-XL support in recent Windows 11 updates.

I've found that sometimes WebP with lossless compression (-lossless) results in smaller file sizes for graphics than JPEG-XL and sometimes it's the other way around.

I see no reason not to use JPEG-XL for archival storage. It is (IMO) the best all-rounder of the current formats, and 20 years from now imagemagick will still be able to convert it to whatever you want.

For video it's not as easy as it takes way more compute and requires hardware support.

You can take any random device and it will be able to decode h264 at 4k. h265 not so much.

As for av1 - my Ryzent 5500GT released in 2024 does not support it.

JPEG is old, and it works.

Images are sorted in folders, per year and some group description based on why they were taken, vacations, event, whatever.

Enable indexing on the folders, and usually there are no freezes to complain about.

> HEIC is good, as long as you pinky promise to never ever leave Apple's ecosystem, ie HEIC sucks.

Not really true in my experience, I have no problems using it in Windows 11, Linux, or with my non-Apple non-Google cloud photos app.

The iPhone using it in an incredibly widespread way has made it a defacto standard.

If you're having trouble in Windows, I wonder if you're running Windows 11 or 10? Because 11 seems a lot better at supporting "modern things" considering that Microsoft has been neglecting Windows 10 for 3 years and is deprecating it this year.

RAW? Storage is becoming cheeper, why discard the originals?

When looking for a format to display HQ photos on my website I settled with a combination of AVIF + JPG. Most photos are AVIF, but if AVIF is too magical comparatively to JPG (like 3x-10x smaller) I use a larger JPG instead. "Magic" means that fine details are discarded.

WebP discards gradients (like sunset, night sky or water) even at the highest quality, so I consider it useless for photography.

just use jpegxl. works great on linux. Pressure software you use to use the proper formats

I recently reencoded my photography archive to webp. It's a static site hosted from S3. I was pretty happy with the size reduction.

> HEIC is good,

It's not. Support is still surprisingly patchy, and it takes a second or so to decode and show the image even on a modern M* Mac. Compared to instant PNG.

> I have a whole bunch of .HEIC photos and I'd really like if Windows Explorer didn't freeze for literal minutes when I open a folder with them.

Indeed.

HEIC for photos taken by my iPhone. Apple stuff seems to do a mostly ok job auto-converting to JPG when needed (I assume, since I haven’t manually converted one in ages).

And JPG for photos taken on a “real” camera (including scanned negatives). Sometimes RAW, but they’re pretty large so not often.

>How in the world do people store images / photos nowadays?

With codecs built for that purpose I hope. Intra-frame misconceptions "formats" should stay that way. A curiosity.

Assuming you are asking about archiving: Use the original format it came in. If you're going to transcode it should be to something lossless like J2K or PNG.

You’re right, for a lot of scenario which is exactly what a standard is there to do, encapsulating the broad strokes.

> Alternatives like WebP might be good for browsers but are nigh-unworkable on desktops, support is very spotty.

Right again, and WebP is the enrichment that goes with the backend when dealing with web. I wouldn’t knock it for not being local compatible, it was designed for the web first and foremost, I think it’s in the name.

I have zero issues with macOS and Linux while using modern image formats. Don’t use Windows, I guess.

> How in the world do people store images / photos nowadays?

PNG where quality matters, JPG where size matters.

>Just as there is a clear winner for video - av1

What?? Maybe I'm too much in aarrrgh circles but it's all H.264 / 265...

>JPEG-XL seemed like the next logical step until Google took their toys and killed it despite already having the support in Chrome,

Why would I ever care about Chrome? I can't use adblockers on Chrome, which makes the internet even less usable than it currently is. I only start up chrome to bypass cross-origin restrictions when I need to monkey-patch javascript to download things websites try to keep me from downloading (or, like when I need to scrape from a Google website... javascript scraper bots seem to evade their bot detection perfectly, just finished downloading a few hundred gigabytes of magazines off of Google Books).

Seriously, fuck Chrome. We're less than 2 years away from things being as bad as they were in the IE6 years.

i don't like working with webp. especially since chrome pushes it on everyting, but googles other tools like slides do not support it. Super annoying, especially since google developed it.

It also doesn't help that most people's experience with webp is force-recompressed versions of images that were originally jpeg. With relatively low quality settings.

JPEG XL is better than webp

Anywhere? I would be super happy if I could open them all in all contexts on my desktop computer.

This reminds me of rust: even if rust will be widespread in 10 or 20 years, it will not really displace C++.

Although I need a engineering explanation as to why COBOL is still alive after all those years, because any tech cannot live forever.

Last I checked you couldn't even upload .webp images to GitHub or Telegram. Well, for GitHub you can cheat by renaming it to .png and GitHub's content detection will make it work regardless, but meh.

> But that is not nearly enough for an image format to reach widespread adoption

I use WEBP extensively but WEBP has a major flaw: it can do both lossy and lossless.

That's the most fucktarded thing to ever do for an image compression format. I don't understand the level of confusion and cluelessness that had to happen for such a dumb choice to have been made.

I've got an entire process around determining and classifying WEBP depending on whether they're lossless or lossy. In the past we had JPG our PNG: life was good. Simple. Easy.

Then dumbfucks decided that it made sense to cram both lossy and lossless under the same umbrella.

> They also want to ensure far future access to their precious photos, when formats like JPEG2000 or even WebP might be long gone.

That however shall never be an issue. You can still open, today, old obscure formats from the DOS days. Even custom ones only use by a very select few software back then.

It's not as if we didn't have emulators, converters, etc. and it's all open source.

Opening old WEBP files in the future shall never ever be a problem.

Determining if it's a lossy or lossless WEBP for non-technical users, however... ; )

I am pretty sure webp is supported everywhere nowadays. I think it is just inertia.

> I mean, webp was made by Google and we know how many of their heavily promoted creations are dead already...

I don't understand this argument. WebP is an algorithm, not a service. You cannot kill it once it's published.

https://news.ycombinator.com/item?id=44298656

You might be getting 100 Mbps to your smartphone; many people – yes, even within the United States – struggle to attain a quarter of that.

> I struggle to understand the justification for other lossy image formats as our networks continue to get faster.

Because Google's PageSpeed and Lighthouse both tell people to use WebP, and a large percentage of devs will do anything Google say in the hopes of winning better SERP placement:

- https://web.dev/articles/serve-images-webp

- https://developer.chrome.com/docs/lighthouse/performance/use...

Exactly! It’s like asking why we still use wheels when hovercrafts exist.

If humans are still around in a thousand years they’ll be using jpegs and they’ll still be using them a thousand years after that. When things work they have pernicious tendency to stick around.

That’s why I am confident LLMs won’t change as much as some may think: after 20+ years of search engines, some still can’t be bothered to do a simple search. (Either that or you’re trolling, I can’t decide I have to say.) Hence, we can wait another 20 years and some will still not use LLMs for everyday questions.

To answer your (false?) question, there’s a long list of benefits, but I’d say HDR and storage efficiency are the two big ones I can think of. The storage efficiency especially is massive, especially with large images.

transparancy? hdr? proper support for lossless? theres many things lacking in jpeg

WebP seems pretty widely supported to me - on Windows at least, Explorer shows thumbnails for them, Paint can open them, other editors like Paint.NET have built-in support... I haven't come across software that doesn't support WebP for a while.

Case in point, DaVinci Resolve. Incredibly popular with people creating videos for YouTube and TikTok, still doesn't support webp in 2025.

This becomes an issue if you're creating content about trending topics, since lots of marketing sites love using webp for every image.

if I want to even download webp and look at the file I need to convert it. barely functional in basic image galleries outside of mobile?

Also missing from popular browsers is support for the new JPEG XL format.

Opus does get use though behind the scenes. Iirc discord uses opus and YouTube uses some pretty exotic audio codecs. No one saves opus files to their computer though.

Opus is too complex. IIRC there is only one full implementation.

This is true, but there are limits. It's a little bit like DEFLAT. Sure, very advanced compressors like Zopfi exist which can get better compression ratios. But then, there's also just Zstd which will get a better compression ratio and compression speed trivially.

I guess you're thinking of jpegli? Do you know how big a difference this actually makes?

This article* makes the case for mozjpeg cleanly beating webp when we are above 500x500px image sizes. So. There's a lot more performance/compression to be gained within the jpeg container format than people generally argue for.

* https://siipo.la/blog/is-webp-really-better-than-jpeg

edit: https://opensource.googleblog.com/2024/04/introducing-jpegli... is likely the real GOAT when it comes to modern jpeg encoders in that it effectively breaks the 8bit color space "ceiling" within the format!

The same thing sort of happened in the compression realm. ZIP is the pretty much the defacto winner for that type of file movement. Oh people use others in a lot of cases. But even when pkzip 2.04 came out there were better ones. Yet here we are still 30 years on using zip. Heck the zip alg is even used in many picture formats.

> Of course there are tons of better formats than JPEG

and webp is not one of them.

Sometimes a format is simply just good enough. The gains that WebP may or may not have definitely do not get it over the hump of being so tied to a browser. AVIF is still very new, but other than the anim stuff, is it enough of an improvement to get people to switch. And that brings me to the entire corpus of existing files. A JPEG decoder will always be necessary based on the amount of preexisting files requiring it. If you have to support JPEG for some, might as well continue making new in the same format as well.

JPEG XL: Better than JPEG in every way aside from legacy support, while being royalty free and open.

You can even "losslessly" compress existing JPEGs to JPEGXL.

JPEG XL is the natural replacement for JPEG and it is perverse that Google backtracked on supporting it.

what about PNG?

It would be interesting to see optimization of compression that's targeted at computer vision processing instead of human visual preferences. What I mean is that instead of making the image look as nice as possible at a certain file size, the goal would be to improve computer vision task performance scores, like running a classifier or segmentation model on that image and evaluating the correctness of the model prediction. A compression algo is better if the model accuracy is higher at a certain file size.

Edit: yes, this has been done https://www.ecva.net/papers/eccv_2020/papers_ECCV/papers/123...

Jinyoung Choi and Bohyung Han, Task-Aware Quantization Network for JPEG Image Compression. ECCV 2020

They're just for different jobs.

JPEG is lossy, in ways that were initially optimized for photographs. The details it loses are often not details photographs are good at providing in the first place. As the upside for losing some data, it gets to pick the data it gets to compress, and it chooses it in such a way as to minimize the size of the compressed data.

PNG is a lossless format. It's practically mandatory when you need 100% fidelity, as with icons or other graphics that are intended to have high contrast in small areas. It's able to optimize large areas of the same color very well, but suffers when colors change rapidly. It's especially unsuitable for photographs, as sensor noise (or film grain, if the source was film) create subtle color variations that are very difficult for it to encode efficiently.

You basically never have a situation where either one is appropriate. They are for different things, and should be used as such.

PNGs for line art and text, JPEGs for photorealistic images.

> When I came up in the IE era

In the IE era I recall, the battle was between GIF and JPEG because IE supported alphatransparent PNGs very poorly :)

> if I recall correctly JPEG as a format can encode an image with a higher fidelity than PNG

The other way around: JPEGs are “lossy” – they throw away visual information to save file size. PNGs, on the other hand, are “lossless”, and decode back to exactly the same pixels that were fed into the encoder.

They're different beasts.

JPEGS are great for photographs, where lossy compression is acceptable.

PNGs can have transparency and lossless compression, so they're great for things like rasterized vector graphics, UI-element parts of a web page, etc.

It depends on the use case.

For archival purposes, where you care about not losing details is more important than image size, PNG is better (though often TIFF is used for that use case). For images with large blocks of solid colors and sharp edges (text, line drawings), PNG is arguable better (though JPEG can be acceptable if you're careful with quality settings). If you need alpha support, go for PNG since JPEG doesn't support that.

For photograph-like images, where image size is important, JPEG is preferred over PNG.

PNG should be used for some types of graphics, like whenever you have big areas of solid color (like logos) or any time you need translucency / transparency. Although, nowadays you can and should use SVG in most of those cases.

JPEG should be used for everything else.

> (if I recall correctly JPEG as a format can encode an image with a higher fidelity than PNG, at least in some circumstances)~

PNG is a lossless format, so I don't think that's possible, unless there's some specific feature that is not available in PNG.

JPEG and PNG don't work the same way. JPEG is lossy - it removes information from the original image, and PNG is lossless. For distribution, like on a website, with JPEG you can compress the image much more than PNG without the users noticing IF the image is photographic. If the JPEG represents a drawing, a screenshot, or contains labels, the lossy compression will be noticeable and PNG is much more appropriate. To keep as master for further modifications and compressions, keeping an image in JPEG format is a bad idea, again because JPEG is lossy. You can't ever encode an image with higher fidelity in JPEG vs PNG but both are useful.

> if I recall correctly JPEG as a format can encode an image with a higher fidelity than PNG, at least in some circumstances

24-bit color PNGs are lossless, to the extent that the input image is encodable in 24 bits of RGB (which is pretty much everything that's not HDR). There's no higher fidelity available for normal input images. If file size limits would force palettized PNGs, it's quite possible for a JPEG at the same file size to have higher fidelity (since it makes a different set of trade-offs, keeping color resolution but giving up spatial resolution instead); but this isn't really a common or particularly valid comparison in the PNG era, was more of an issue when comparing to GIFs.

tl;dr: Nope, PNG is perfect. JPEG can approach perfect, but never get there. Comparison is only interesting with external (e.g. file size) constraints.

Chrome's JPEG-XL removal was officially due to low usage metrics and prioritization concerns, not just competitive motives - Google's own engineers were divided on the decision, with many supporting JXL's technical merits.

Being a much more complicated format than JPEG (WebP is based on the VP8 video codec) invites a huge attack surface because it requires so much more code to support. On top of that, the fact that 99% of people (even Apple's ImageIO!) use Google's libwebp means any exploit can hit almost everyone all at once. This has actually happened:

- https://nvd.nist.gov/vuln/detail/CVE-2023-41064

- https://nvd.nist.gov/vuln/detail/CVE-2023-41061

- https://nvd.nist.gov/vuln/detail/CVE-2023-4863

- https://citizenlab.ca/2023/09/blastpass-nso-group-iphone-zer...

The lack of support makes me suspicious of it. If even Google Docs finds it too difficult to prioritize webp support, idk if there's some hidden problem with ease of implementation.

As an enduser, I hate, hate, hate webp, because I cant' easily use the images in a wide range of ways.

Maybe it's vaguely more flexible and compresses well. I don't care. If someone uses it, I despise them.

I do handle files myself, but almost nothing keeps me on MP3. The only time I've even seen an MP3 in the past few years was when trying to get music into an old car system, which also sucked so much (e.g. shuffle feature with replacement) that I went back to just using the aux.

The Western World perspective on this platform generates quite funny statements sometimes. Outside of it, mp3 is still quite popular and normal.

Even within the Western World, there are many people who like to own their digital music.

Almost every new submission to Hacker News gets [dead] and [flagged] for no reason, and somebody has to vouch for it. I don't know if it's automated system or some kind of activists who are stalking the New section.

In 99% cases of "Why wasn't this (better) format adopted?" the answer is:

* It's not actually better.

* It's patented/requires license/is owned by someone who wants a lot of royalties.

JPEG2000 is of the second variety.

Orthogonal, but one fun thing about JPEG 2000 is that when you watch a movie at movie theatres now, odds are overwhelming that you are watching a sequence of JPEG 2000 encoded images.

Multiple reasons, while technically better and more benign compression artifacts, it is computationally more expensive, limited quality improvements, encumbered by patents, poor Metadata format, poor colorspace support... In the end, the benefits aren't great enough compared to jpeg to change the default format

IIRC JPEG2000 was never supported by any browser other than Safari, and even Safari recently gave up and removed support (around the same time they added support for JPEG XL). As to why other browsers never supported it, I'm not sure.

JPEG 2000 used to be a patent minefield.

Greed. Wavelets used to be heavily patented.

Thoughts on jxl?

have you tried QOI? ;)

JPEG-XL is supported by exactly 1 browser. WebP and AV1F are supported by just about every browser.

I'd love to use JPEG-XL, but I'm guessing the only way to do that is also bringing along a WASM decoder everywhere I want to use it.

Upload a JPEG, gets converted to WEBP next person, downloads WEBP converts it to JPEG to actually edit it in software because even things like Photoshop/MacOS Preview can't edit one natively, saves to JPG and uploads, gets converted to WEBP

next person downloads the now JPEG's WEBP'd JPEG'd WEBP'd image

fast forward a decade the original quality versions of the images no longer exist just these degraded

So, what you are saying is that JPEG-XL is superior, as long as your use case is insensitive to whether the majority of web users can view your content?

I enjoy webp lossless mode

I'm not going to use webp or jpeg-xl.

JPEG XL is superior... just like how Betamax was visually superior.

I've recently been battling with github not having support for WebP. Seems odd for a website not to support an image format when the browser does.

> Most websites break with WebP

That part at least isn't true.