42 ms·

Why JPEGs still rule the web (2024)

224 points by purpleko 1y ago

reddalo 1y ago
The article only briefly mentions the real problem: outside of browsers, proper support for .webp files is very, very low. That's why JPEG is still king and probably still be for a long time.
- Acrobatic_Road 1y ago
  Also missing from popular browsers is support for the new JPEG XL format.
  - pbhjpbhj 1y ago
    https://caniuse.com/jpegxl https://caniuse.com/jpegxl Looks like a mixture of runtime and compiler flags are needed except for Safari.
- nemomarx 1y ago
  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?
  - k__ 1y ago
    Sometimes you upload a jpeg, they convert it to webp, and then don't allow uploading webps.
    - palmfacehn 1y ago
      I had uploaded lossless webp images, the 3rd party site cached the images from my server and re-encoded them as lossy format of a higher file size and lower fidelity.
      - edflsafoiewq 1y ago
        They'll do that to large PNGs too.
  - throawayonthe 1y ago
    in software made in the past decade? seems unlikely
- AshleysBrain 1y ago
  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.
  - jhoechtl 1y ago
    Right so on Linux/KDE. Is missing WebP support a meme?
    - freedomben 1y ago
      Yep, on Gnome we have both eog and GIMP that support webp completely, and have for many years. I don't think I've even tried with other apps but haven't needed to. I didn't even realize this was a problem for some platforms
  - frollogaston 1y ago
    Google Docs, of all things, does not support webp. Preview on Mac can open it but not edit. Those are my two most common use cases.
    - coryrc 1y ago
      I celebrated the anniversary of the (internal) bug asking for SVG support in Google slides. I think it's up to 15 years now? So, uh, don't get your hopes up.
      - frollogaston 1y ago
        Well SVGs I understand being harder to support, those aren't really images. And various anti-injection security rules treat it as untrusted HTML code.
        pimlottc 1y ago
        There is a workaround for using SVG in Google Slides by using Google Drive to convert to EMF (a format I’ve never heard of anywhere else). It’s a pain, though. https://graphicdesign.stackexchange.com/questions/115814/how-can-i-import-a-vector-drawing-into-google-slides https://graphicdesign.stackexchange.com/questions/115814/how...
- CM30 1y ago
  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.
MallocVoidstar 1y ago
JPEG: No active patents, universal support, good enough. HEIC: Have fun licensing this. WebP: Slightly better than JPEG maybe, but only supports 1/4 chroma resolution in lossy mode so some JPEGs will always look better than the equivalent WebP. AVIF: Better than JPEG probably, but encoders for AV1 are currently heavily biased towards blurring, even at very high bitrates. Non-Chrome browser support took a while.
- _kidlike 1y ago
  what about PNG?
  - kccqzy 1y ago
    Apples and oranges. PNGs aren't used for photographic images. It's good for line art, certain cartoons, pixel art and the like.
  - zargon 1y ago
    Entirely different category.
- llm_nerd 1y ago
  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.
  - deleted 1y ago
    [deleted]
  - addaon 1y ago
    > JPEG XL: Better than JPEG in every way aside from legacy support, while being royalty free and open. And decoder complexity. A software JPEG decoder is a weekend project. A hardware JPEG decoder not much more. Doing the same for arbitrary JPEG XL files is much, much more complicated. In any world where any of development cost, implementation complexity, expected code quality (especially when using first-order assumptions like constant number of defects per line of code), or decoder resources (especially for hardware implementations) are important, JPEG has serious advantages.
fastball 1y ago
> These days, the format is similar to MP3 or ZIP files—two legacy formats too popular and widely used to kill. While killing MP3 might be difficult, the vast majority of people aren't handling audio files themselves these days, so probably not hard to phase out fairly rapidly.
- Krasnol 1y ago
  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.
  - geerlingguy 1y ago
    I still encode everything in MP3. The files work on my 20 year old SanDisk player, my original iPod, my iPhone, Mac, Chromebook, Windows laptop, MP3 CDs in our 08 minivan... It's nice to have that consistent ubiquity, something very hard to find these days. Especially if you're entire audio library (audio books, podcasts, songs) comes from some streaming service that requires an app!
    - frollogaston 1y ago
      The poor quality is a dealbreaker for me. Yes it's fine with a high enough bitrate, but there isn't ubiquitous support for that.
      - encom 1y ago
        What decoders don't support VBR MP3 at this point? You would have to go back at least 20 years to find software that breaks on VBR. Maybe some very very terrible hardware decoder chokes on it? Incidentally, breakage on VBR bitstreams is buggy behaviour, because some lazy developers assumed frame sizes would never change. VBR is completely within spec, and decoders do not have to explicitly support it. Lastly a note on bitrate: 320 kbps CBR (the max allowed in spec) is often wasteful and pointless. In many cases, an encoder will pad out frames to conform to the requested bitrate. Indeed tools exist that will losslessly re-encode a CBR file to VBR by removing the padding, producing a smaller file. MP3 (as good as it is) has certain problem samples that aren't fixed by throwing more bits at them. A competent encoder with proper settings, like lame which defaults to -V4 is transparent in most samples to most people. If you disagree you should double-blind test yourself.
echelon 1y ago
Nothing supports WebP. Most websites break with WebP. Desktop tools choke on WebP. It sucks, because it's a good format.
- afavour 1y ago
  > Most websites break with WebP That part at least isn't true.
  - edflsafoiewq 1y ago
    Probably they mean uploading WebPs where an image is expected often doesn't work.
    - echelon 1y ago
      Yes, I was referring to the backends. A funny case in point: Sora.com produces WebP outputs, but you can't turn around and use them as inputs. (Maybe they've fixed that?) Smaller websites almost always reject them. Even within big websites, support is fractured within the product surface area. You can't use them as Reddit profile icons, for instance. One of the most apparent issues is that a lot of thumbnailing and CDN systems don't work natively with WebP, so you have to reject WebP outright until broader support is added. Once the WebPs are in your systems, you have to make sure everything downstream can support them... it's infectious. Really unfortunate that we haven't been able to move past this.
  - martin_a 1y ago
    You can think about WordPress what you want, but afaik it does not allow to upload WebP files to its media gallery without any additional plugins while being said to run large parts of the internet...
    - celsoazevedo 1y ago
      Just tested on my self-hosted WordPress blog and it works without any plugins. WebP support was added to WordPress in 2021 with version 5.8: https://wordpress.org/documentation/wordpress-version/version-5-8/#adding-support-for-webp https://wordpress.org/documentation/wordpress-version/versio... AVIF support in 2024, with v6.5: https://make.wordpress.org/core/2024/02/23/wordpress-6-5-adds-avif-support/ https://make.wordpress.org/core/2024/02/23/wordpress-6-5-add...
bob1029 1y ago
Beyond the compression (which is amazing), JPEG is also extremely fast when implemented well. I'm not aware of any other image format that can encode at 60fps+ @ 1080p on a single CPU core. Only mild SIMD usage is required to achieve this. With dedicated hardware, the encode/decode cost quickly goes to zero. I struggle to understand the justification for other lossy image formats as our networks continue to get faster. From a computation standpoint, it is really hard to beat JPEG. I don't know if extra steps like intra-block spatial prediction are really worth it when we are now getting 100mbps to our smartphones on a typical day.
- MrDOS 1y ago
  https://news.ycombinator.com/item?id=44298656 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.
  - bob1029 1y ago
    What is the likelihood of experiencing precisely marginal network conditions wherein webp improves the user experience so dramatically over jpeg that the user is able to notice? If jpeg is loading like ass, webp probably isn't going to arrive much faster.
    - MrDOS 1y ago
      I'm sorry, I misunderstood your doubt of the usefulness of other lossy formats as criticism of using lossy formats in general in the face of higher bandwidth. Reading too fast, never mind me... :)
  - GuB-42 1y ago
    If you have slow internet on your smartphone, chances are that you also have a slow smartphone, and therefore decoding performance matter, it may also save you a bit of battery life for the same reason, which may be important in place with little internet coverage. You have to find a balance, and unless (still) pictures are at the center of what you are doing, it is typically only a fraction of the bandwidth (and a fraction of the processing power too). We are not talking about 100 Mbps, we downloaded JPEGs from dialup connections you know. You don't even need to go into the Mbps unless you are streaming MJPEG (and why would you do that?).
77pt77 1y ago
How come jpeg 2000 never became popular?
- llm_nerd 1y ago
  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.
  - 77pt77 1y ago
    So like mjpeg but for jpeg 2000? That doesn't even make much sense because you lose inter-frame compressibility
    - meindnoch 1y ago
      Every frame is a keyframe in digital cinema. It's literally a bunch of JPEG2000 files, wrapped in an MXF container. A typical 2hr movie is in the 300-400GB ballpark.
- AshleysBrain 1y ago
  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.
- SimplyUnknown 1y ago
  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
- Maken 1y ago
  JPEG 2000 used to be a patent minefield.
- 1y ago
no_wizard 1y ago
EDIT: I was wrong, and had PNG and JPEG formats backward. As others correctly pointed out PNG is lossless where as JPEG is lossy. PNG is better for marketing / UI / artistic imagery and JPEG for photographs due to the tolerance for JPEGs lossy encoding with photographs, seems to be the generally accepted opinion now. Regardless, since the picture tag[0] was introduced I’ve used that for most image media by default with relevant fallbacks, with WebP as default. Also allows loading relevant sized images based on media query which is a nice bonus [0]: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/picture https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
- Tobani 1y ago
  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.
  - kevingadd 1y ago
    PNGs are also ideal for color accuracy since one of the things you lose quickly when converting to JPEG is the ability to have an exact RGB value flow from input to output, even at a high quality level. So if you want i.e. a banner graphic to seamlessly blend in with your site's background color, JPEG is worse for that.
    - martin_a 1y ago
      Sorry, but that sounds more like a problem with your color management systems and workflows and not so much with JPEG itself.
      - kevingadd 1y ago
        JPEGs are intrinsically YCbCr not RGB, so I don't know how you would avoid some precision loss when you combine that colorspace conversion with things like the quality level and (potentially) subsampling.
jmyeet 1y ago
So there are two use cases for public image dissemination: 1. Lossy: JPEG fills this role; 2. Lossless: this was GIF but is now PNG; and 3. Animated: GIF. So for a format to replace JPEG, it must bring something to the table for lossy compression. Now that JPEG is patent-free, any new format must be similarly unencumbered. And it's a real chicken-and-egg problem in getting support on platforms such that people will start using it. I remember a similar thing happening with Youtube adding VP9 (IIRC) support as an alternate to H264, which required an MPAA patent license. The MPAA also tried to cloud VP9 by saying it infringed on their patents anyway. No idea if that's true or not but nobody wants that uncertainty. Anyway, without total support for VP9 (which Apple devices didn't have, for example) Youtube would need to double their storage space required for videos by having both codecs. That's really hard to justify. Same goes for images. You then need to detect and use a supported image format... or just use JPEG.
greenavocado 1y ago
DO NOT USE WEBP JPEG-XL is the superior format. The only reason WebP exists is not because of natural selection, but because of nepotism (Google Chrome). https://www.reddit.com/r/AV1/comments/ju18pz/generation_loss_comparing_jpeg_webp_jxl_and_avif/ https://www.reddit.com/r/AV1/comments/ju18pz/generation_loss...
- dragonwriter 1y ago
  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?
  - Spivak 1y ago
    I mean if you define superior not in terms of its technical merits but because of its blessed status by Google. It's not a terrible format but it is very much "what is the worst quality we can reasonably get away with to save on bandwidth." Such a thing does have its uses. At some point you have to be pragmatic and meet users where they are but doesn't mean you have to like that Google did throw their weight around in a way that only they really can.
    - dragonwriter 1y ago
      > I mean if you define superior not in terms of its technical merits “Technical merits” are rarely, for anything, the sole measurement of fitness for purposes. Even for purely internal uses, internal social, cultural, and non-technical business constraints often have a real impact on what is the best choice, and when you get out into wider uses with external uses, the non-technical factors proliferate. That's just reality. I understand the aesthetic preference to have decisions only require considering a narrow set of technical criteria which you think should be important, but you will make suboptimal decisions in the vast majority of real-world circumstances if you pretend that the actual decision before you conforms to that aesthetic ideal.
  - Zardoz84 1y ago
    just fuking use a poly fill to add support of JPEG XL. Or store JPEG XL and convert on the fly to JPEG to supply it to browsers that don't support JPEG XL.
JacobiX 1y ago
I loved the article, but it overlooks one important point: although the JPEG format is frozen, encoders are still evolving ! Advances such as smarter quantization, better perceptual models, and higher-precision maths enables us achieve higher compression ratios while sticking to a format that's supported everywhere :)
- edflsafoiewq 1y ago
  I guess you're thinking of jpegli? Do you know how big a difference this actually makes?
  - ksec 1y ago
    Anywhere from 5-15% if I remember correctly depending on source material. I was at one point thinking this would make JPEG-XL and AV1F moot because all of a sudden JPEG became good enough again. But the Author of JPEG-XL suggest there is still so much JPEG-XL encoder can do to further optimise bit / quality especially in the bpp below 1.0 range.
  - JacobiX 1y ago
    MozJPEG, Guetzli and also Jpegli
  - qingcharles 1y ago
    Jpegli is designed from the ashes of JPEG-XL (same author), both from Google. IIRC he also had a hand in the PNG format?
- cogman10 1y ago
  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.
imageformatssux 1y ago
How in the world do people store images / photos nowadays? 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. JPEG is... old, and it shows. The filesizes are a bit bloated, which isn't really a huge problem with modern storage, but the quality isn't great. 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?) HEIC is good, as long as you pinky promise to never ever leave Apple's ecosystem, ie HEIC sucks. AVIF seems computationally expensive and the support is pretty spotty - 8bit yuv420 might work, but 10b or yuv444 often doesn't. Windows 10 also chokes pretty hard on it. Alternatives like WebP might be good for browsers but are nigh-unworkable on desktops, support is very spotty. PNG is cheap and support is ubiquitous but filesizes become sky-high very quick. 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. Is jpeg still the only good option? Or is encoding everything in jpeg-xl or avif + praying things get better in the future a reasonable bet?
- SAI_Peregrinus 1y ago
  I store Raw + PSD with edits/history + whatever edited output format(s) I used.
- tristor 1y ago
  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.
  - Zardoz84 1y ago
    There is NO quality loss when converting from JPEG XL to JPEG and vice versa. It was done by design. Not an accident.
legitster 1y ago
This takes me back to when the goal of a webpage was to be less than 1Mb. At the time, the only reason to use PNG (such luxury) was when you needed transparency. The variable compression of JPEG was very important. In Photoshop you could just grab an image and choose the file size you needed and the JPEG quality would degrade to match your design constraints.
deleted 1y ago
[deleted]
politelemon 1y ago
The last part of the article about jpeg being outpaced seems anecdotal or unsubstantiated, it needs context.
hungryhobbit 1y ago
I love how the article implies there's something flawed about webp at the end ... but if you click the link the only "flaw" reported is that webp isn't ubiquitous enough yet, so some sites don't support it Perfect logic: let's not switch to webp because it's bad. Why is it bad? Not everyone has switched to it yet.
- msabalau 1y ago
  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.
  - mr_toad 1y ago
    > a wide range of ways. I hear this all the time but I have yet to encounter it. Is it just social media and lolcats? Maybe the software I’m using is too uncool to not support it.
- frollogaston 1y ago
  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.
- Lammy 1y ago
  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-41064 - https://nvd.nist.gov/vuln/detail/CVE-2023-41061 https://nvd.nist.gov/vuln/detail/CVE-2023-41061 - https://nvd.nist.gov/vuln/detail/CVE-2023-4863 https://nvd.nist.gov/vuln/detail/CVE-2023-4863 - https://citizenlab.ca/2023/09/blastpass-nso-group-iphone-zero-click-zero-day-exploit-captured-in-the-wild/ https://citizenlab.ca/2023/09/blastpass-nso-group-iphone-zer...
ksec 1y ago
I want to add a slightly off topic point here. This submission was originally shown as [dead]. I have no idea why, I read some of the content and seems decent enough, especially in the current state of things when JPEG-XL is blocked because of AOM / Google Chrome. I vouched for it and upvoted, then somehow it is on the front page. I wonder if dead means somehow flagged it. If so, then why? If not, why is it dead?
- carlosjobim 1y ago
  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.
  - encom 1y ago
    Flagging seems to be used like a super downvote on both submissions and comments. Admins appear okay with it.
martin_a 1y ago
As others have pointed out, JPEG is just fine. It's "enough" in the best sense of the word and gets its job done. It's supported on every device, in every browser, image viewer and whatnot. It. Just. Works. Maybe there are formats that compress better or lossless, but thanks to advancements in disk space and transfer rates (I know, not everywhere but penetration and improvement will happen...) the disadvantages of JPEG can be handled and we can just enjoy a very simple file format. In an era where enshitification lingers around every corner I'm just happy that I don't need to think about whether I have to convert _every digital picture I've ever taken_ into some next-gen format because some license runs out or whatnot. It just works. Let's enjoy that and hope it sticks around for 30 more years.
poisonborz 1y ago
The actual issue is that this is not an issue for the users. Only global providers, so they were the ones pushing "obscure" solutions. Music fidelity was more of a consumer problem, so formats like FLAC found a foothold besides the go-to one.
t1234s 1y ago
I notice webp produces images about 20% smaller than mozilla jpeg while appearing slightly sharper. I use a <picture> element to offer webp versions first but always include jpeg versions for future-proofing.
wolf550e 1y ago
The reason JPEGs still rule is because Google Chrome removed support for JPEG-XL, the actually better photo format, because the Google guys who did AVIF decided they don't want competition.
- ethan_smith 1y ago
  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.
modeless 1y ago
The amazing thing about JPEG is people are still squeezing out backwards compatible compression improvements 30 years later. Mozjpeg is well known by now, but Jpegli was just published last year and does even better at high bitrates[1]. It's hard to want to adopt newer formats when they keep getting squeezed by further improvements to good old JPEG. [1] https://opensource.googleblog.com/2024/04/introducing-jpegli-new-jpeg-coding-library.html https://opensource.googleblog.com/2024/04/introducing-jpegli...
- bonoboTP 1y ago
  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/123650307.pdf 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
shmerl 1y ago
I'm trying to replace jpeg with avif in my use cases, but some sites still don't handle avif. Even Github! Though the latter doesn't support IPv6 either.
lucgommans 1y ago
> It’s been difficult to remove [old JPEG] from its perch. [...] the formats AVIF and HEIC, each developed by standards bodies, have largely outpaced [JPEG] I'm currently sticking to JPEG because, last time I tried, JPEG came out as the best format. Referencing my memory at https://chaos.social/@luc/113615076328300784 https://chaos.social/@luc/113615076328300784 - JPEG has two advantages on slow connections: the dimensions are either stored up front so the layout doesn't jump, or maybe the renderer is better; and it loads a less-sharp version first and progressively gets sharper - JPEG was way faster when compressing and decompressing - on the particular photo I wanted to optimise in this instance, JPEG was also simply the best quality for a given filesize which really surprised me after 32 years of potential innovation Regarding AVIF, my n=1 experience was that it "makes smooth gradients where jpeg degrades to blotchy pixels, but at decent quality levels, jpeg preserves the grain that makes the photo look real". Gradients instead of ugliness at really small sizes can be perfect for your use-case, but note that it's also ~80 times slower at compression (80s vs. <1s) JpegXL isn't widely in browsers yet so I couldn't use it > These days, the [JPEG] format is similar to MP3 The difference with mp3 is that Opus is either a bit better or much better, but it's always noticeably better. You can save ~half the storage space. For speech (audio books) I use 40kbps, and for music maybe 128kbps which is probably overkill. And I delete the originals without even checking anymore if it really sounds the same, I noticed that I simply can't tell the original apart in a blind test, no matter what expensive headset setup I try TFA attributes it to a simple "they were first" advantage, but I think this is why "Why JPEGs still rule the web": no file format is better than JPEG in the same way as Opus is better than MP3; in that you don't have to think about it anymore and it's always a win in either filesize or quality That said, Opus is also annoyingly hard to get into people's minds, but I've done it and you also see major platforms from compress-once-serve-continuously video (e.g. Youtube) to VoIP (e.g. Whatsapp) switching over for all their audio applications
GuB-42 1y ago
Because JPEG just works. It is not the best by far, but everybody supports it, and it is usually not worth saving a few bytes in exchange for worse support, added complexity and extra processing. Lossy compressed images are usually not the most significant consumers of bandwidth and disk space. Videos are. That's why there have been a lot more focus on video formats than anything else, there is a lot to gain here, not so much with still images. JPEG-XL is super-complicated because it supports plenty of things most people don't really need. Webp is somewhat better supported because it is backed by Google, it is also what is essentially a single frame video, so if you did the hard work on video (where it matters), you get images almost for free, and it saves Google a tiny bit of bandwidth, and "a tiny bit" is huge at Google scale. We are seeing the same thing with audio. MP3 (1991) is still extremely popular, the rest is mostly M4A/AAC (2001). We pretty much have had the perfect audio format now, which is Opus (2012) and yet, we don't even use it that much, because the others are good enough for what we make of them.
- Gigachad 1y ago
  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.
  - maeln 1y ago
    It also is used in video games. OGG/Libvorbis was already pretty popular (probably because it was free of patent), and opus has seen some use.
- RadiozRadioz 1y ago
  Opus is too complex. IIRC there is only one full implementation.
neuroelectron 1y ago
I think it's about time we switched from JPEGs to Rust.
karim79 1y ago
I've no single clue as to the future of image formats. All or them (or almost) have merits and stuff they suck at. I've been building a service which makes no judgement about it but tries to provide all the choices. JXL will be added soon: https://kraken.io https://kraken.io
cadamsdotcom 1y ago
“Because it has a 30 year head start. And there are better, new, formats coming all the time; but everyone supporting them hates each other.”
tsoukase 1y ago
There are only two kinds of image file formats: the ones people complain about and the ones nobody uses.
userbinator 1y ago
I have written a JPEG, GIF, and PNG decoder. All easily weekend projects. As for the other two I've attempted the same for: JPEG2000: insanely complex and nonintuitive, especially the edge-cases and overly flexible encoding decisions WebP: also complex, and effectively Google-proprietary
- panja 1y ago
  Thoughts on jxl?
- NooneAtAll3 1y ago
  have you tried QOI? ;)
hoseja 1y ago
There is an photo example for quality levels throughout the article but instead of classical JPEG compression artifacts it just seems to get progressively more posterized. What's up with that.
carra 1y ago
We keep hearing different variants of "webp should take over because now it has good browser support". But that is not nearly enough for an image format to reach widespread adoption. People want to be able to open the images anywhere (what about watching photos in a smartTV? or an old tablet? what about digital picture frames?). They want to edit the images in any program (what about this FOSS editor? what about the many people stuck in pre-subscription Photoshop versions?). They also want to ensure far future access to their precious photos, when formats like JPEG2000 or even WebP might be long gone. I mean, webp was made by Google and we know how many of their heavily promoted creations are dead already...
- whyever 1y ago
  > 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.
  - carra 1y ago
    Fair enough. What I meant by this is that, in the end, most software that decides to add webp support is doing it because of the huge push by Google to do so. But if they suddenly change that push to something else then webp might find itself growing more irrelevant.
    - nottorp 1y ago
      I didn't know webp was pushed by Google. They should publicize that fact more so people know to avoid the format entirely. What Google pushes is in their self interest and has nothing to do with the good of the unwashed masses.
      - graealex 1y ago
        WebP is basically a single i-frame from the WebM video codec, which literally was developed by Google to avoid paying license cost for H.264. For which they had great incentive. WebP is to WebM what HEIC is to HEVC. You can argue that using free codecs is a collateral benefit here, even though Google did it for selfish reasons. It is not detrimental to the public or the internet.
scrapheap 1y ago
I'm sure that I'm not the only person here being reminded by this that over 30 years ago they were being amazed by viewing JPEGs on their Amiga using HAM mode...
alex77456 1y ago
I'm surprised some multi-encoder container format didn't take over by now, seeing as there is no one size fits all clear winner so far.
suspended_state 1y ago
It's the VHS of digital image compression and storage.
Blahagun 1y ago
Of course there are tons of better formats than JPEG but it needs to be understood that the most important feature of JPEG is to be exchangeable. It doesn't matter what your shiny new web browser supports, JPEG is considered supported everywhere and all editorials actually refuse to accept anything other than JPEG. You can't just break everyone's workflow because Google decided to force WebP (for purely selfish reasons, of course). The web browser is actually one of the least important platforms for JPEG. To day JPEG still executes its mission perfectly and with huge bandwidth increases it doesn't even matter how large the file is.
- hulitu 1y ago
  > Of course there are tons of better formats than JPEG and webp is not one of them.
- dingdingdang 1y ago
  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 https://siipo.la/blog/is-webp-really-better-than-jpeg edit: https://opensource.googleblog.com/2024/04/introducing-jpegli-new-jpeg-coding-library.html 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!
- sumtechguy 1y ago
  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.
  - wongarsu 1y ago
    It helps that in most cases when people make a zip the compression is a secondary feature. What people want 90% of the time is a container format to put multiple files or a whole folder structure into one file. .zip or .tar.gz do this just fine, even if their compression factor and speed aren't that great by modern standards. Same with jpeg: Most people want to just encode images, reducing file size by 10% is a negligible win for most people
nottorp 1y ago
> Thirty-eight years later, we’re still using the GIF—but it never rose to the same prevalence of JPEG. > The GIF was a de facto standard. The JPEG was an actual one I know this is IEEE but seriously? JPEG won because it was a formal standard? Didn't JPEG win because it supported more than 256 colours and, with the lossy compression, greatly reduced file size and bandwidth needs for our cat photo and porn collections? While proposed replacements ... solve what problems?
RugnirViking 1y ago
The single biggest things that could be done to remedy this in order 1) snipping/clipping/screenshot tool outputs webp 2) convert to webp on ctrl-c ctrl-v from browsers 3) whatsapp/messenger/discord support. People will say these work fine, in my experience its a gamble, which is shouldn't be. It should be seamless, literally no edge cases
whizzter 1y ago
While the article is mostly good one glaring technical error annoys me. "The stronger the cosine transformation, the more compressed the final result" is simply wrong. DCT (and the inverse DCT) are transforms that transform between "sample" and "frequency" domains, it's well defined should be perfectly reversible without compression (iirc the one in JPEG should be lossless given as many bits as the samples themselves). The trick of DCT based compression is that humans don't notice when information disappears from higher frequencies(also in _natural images_ there is often little data in high frequencies, often lots of 0 that can be immediately cut). So harder compression means removing more high frequency data from storage without it being too noticeable when reconstructing samples from the frequency domain at decompression. Conversly however, if you have "sharp edges" in the sample data you need more higher frequencies to reproduce the sharp edges without "ringing" artefacts (this is why you will see noisy blocks around text in highly compressed JPEG's with text since it runs out of bandwidth to adjust). The frequency domain values, and how compression affects removing various frequencies(black and white in the filter images) can be illustrated on the wikipedia filter comparsion example image below. (low frequencies are in the upper-left corner of the filter and spectrum images whilst higher frequencies horizontally are to the right and higher vertical frequencies are towards the bottom). https://en.wikipedia.org/wiki/File:DCT_filter_comparison.png https://en.wikipedia.org/wiki/File:DCT_filter_comparison.png https://en.wikipedia.org/wiki/Discrete_cosine_transform https://en.wikipedia.org/wiki/Discrete_cosine_transform (Mainly "Example of IDCT" section towards the bottom but also the preceding ones).
donatj 1y ago
We started using AVIFs recently in picture elements with fallback to JPEG, and I'm a pretty big fan. The compression is good, the tooling is decent. They're supported by most things natively. Browser support for AVIF is nearly good enough that you might not need the fallback in reality. The only real problem I have encountered is that animated AVIFs are super stuttery in Safari for some reason.
dev1ycan 1y ago
JPEG-XL on Chrome is a perfect example of why Google should have Chrome taken away from it.
einpoklum 1y ago
> These days, the format is similar to MP3 or ZIP files—two legacy formats too popular and widely used to kill. Are MP3's not dying out gradually, like, say, WAVs have? I mean, do people/organizations actually encode anything to MP3 rather than AAC, these days?

224 points by purpleko 1y ago

The article only briefly mentions the real problem: outside of browsers, proper support for .webp files is very, very low. That's why JPEG is still king and probably still be for a long time.

Acrobatic_Road 1y ago
Also missing from popular browsers is support for the new JPEG XL format.
- pbhjpbhj 1y ago
  https://caniuse.com/jpegxl https://caniuse.com/jpegxl Looks like a mixture of runtime and compiler flags are needed except for Safari.
nemomarx 1y ago
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?
- k__ 1y ago
  Sometimes you upload a jpeg, they convert it to webp, and then don't allow uploading webps.
  - palmfacehn 1y ago
    I had uploaded lossless webp images, the 3rd party site cached the images from my server and re-encoded them as lossy format of a higher file size and lower fidelity.
    - edflsafoiewq 1y ago
      They'll do that to large PNGs too.
- throawayonthe 1y ago
  in software made in the past decade? seems unlikely
AshleysBrain 1y ago
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.
- jhoechtl 1y ago
  Right so on Linux/KDE. Is missing WebP support a meme?
  - freedomben 1y ago
    Yep, on Gnome we have both eog and GIMP that support webp completely, and have for many years. I don't think I've even tried with other apps but haven't needed to. I didn't even realize this was a problem for some platforms
- frollogaston 1y ago
  Google Docs, of all things, does not support webp. Preview on Mac can open it but not edit. Those are my two most common use cases.
  - coryrc 1y ago
    I celebrated the anniversary of the (internal) bug asking for SVG support in Google slides. I think it's up to 15 years now? So, uh, don't get your hopes up.
    - frollogaston 1y ago
      Well SVGs I understand being harder to support, those aren't really images. And various anti-injection security rules treat it as untrusted HTML code.
      - pimlottc 1y ago
        There is a workaround for using SVG in Google Slides by using Google Drive to convert to EMF (a format I’ve never heard of anywhere else). It’s a pain, though. https://graphicdesign.stackexchange.com/questions/115814/how-can-i-import-a-vector-drawing-into-google-slides https://graphicdesign.stackexchange.com/questions/115814/how...
CM30 1y ago
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.

MallocVoidstar 1y ago

JPEG: No active patents, universal support, good enough. HEIC: Have fun licensing this. WebP: Slightly better than JPEG maybe, but only supports 1/4 chroma resolution in lossy mode so some JPEGs will always look better than the equivalent WebP. AVIF: Better than JPEG probably, but encoders for AV1 are currently heavily biased towards blurring, even at very high bitrates. Non-Chrome browser support took a while.

_kidlike 1y ago
what about PNG?
- kccqzy 1y ago
  Apples and oranges. PNGs aren't used for photographic images. It's good for line art, certain cartoons, pixel art and the like.
- zargon 1y ago
  Entirely different category.
llm_nerd 1y ago
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.
- deleted 1y ago
  [deleted]
- addaon 1y ago
  > JPEG XL: Better than JPEG in every way aside from legacy support, while being royalty free and open. And decoder complexity. A software JPEG decoder is a weekend project. A hardware JPEG decoder not much more. Doing the same for arbitrary JPEG XL files is much, much more complicated. In any world where any of development cost, implementation complexity, expected code quality (especially when using first-order assumptions like constant number of defects per line of code), or decoder resources (especially for hardware implementations) are important, JPEG has serious advantages.

fastball 1y ago

> These days, the format is similar to MP3 or ZIP files—two legacy formats too popular and widely used to kill. While killing MP3 might be difficult, the vast majority of people aren't handling audio files themselves these days, so probably not hard to phase out fairly rapidly.

Krasnol 1y ago
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.
- geerlingguy 1y ago
  I still encode everything in MP3. The files work on my 20 year old SanDisk player, my original iPod, my iPhone, Mac, Chromebook, Windows laptop, MP3 CDs in our 08 minivan... It's nice to have that consistent ubiquity, something very hard to find these days. Especially if you're entire audio library (audio books, podcasts, songs) comes from some streaming service that requires an app!
  - frollogaston 1y ago
    The poor quality is a dealbreaker for me. Yes it's fine with a high enough bitrate, but there isn't ubiquitous support for that.
    - encom 1y ago
      What decoders don't support VBR MP3 at this point? You would have to go back at least 20 years to find software that breaks on VBR. Maybe some very very terrible hardware decoder chokes on it? Incidentally, breakage on VBR bitstreams is buggy behaviour, because some lazy developers assumed frame sizes would never change. VBR is completely within spec, and decoders do not have to explicitly support it. Lastly a note on bitrate: 320 kbps CBR (the max allowed in spec) is often wasteful and pointless. In many cases, an encoder will pad out frames to conform to the requested bitrate. Indeed tools exist that will losslessly re-encode a CBR file to VBR by removing the padding, producing a smaller file. MP3 (as good as it is) has certain problem samples that aren't fixed by throwing more bits at them. A competent encoder with proper settings, like lame which defaults to -V4 is transparent in most samples to most people. If you disagree you should double-blind test yourself.

echelon 1y ago

Nothing supports WebP. Most websites break with WebP. Desktop tools choke on WebP. It sucks, because it's a good format.

afavour 1y ago
> Most websites break with WebP That part at least isn't true.
- edflsafoiewq 1y ago
  Probably they mean uploading WebPs where an image is expected often doesn't work.
  - echelon 1y ago
    Yes, I was referring to the backends. A funny case in point: Sora.com produces WebP outputs, but you can't turn around and use them as inputs. (Maybe they've fixed that?) Smaller websites almost always reject them. Even within big websites, support is fractured within the product surface area. You can't use them as Reddit profile icons, for instance. One of the most apparent issues is that a lot of thumbnailing and CDN systems don't work natively with WebP, so you have to reject WebP outright until broader support is added. Once the WebPs are in your systems, you have to make sure everything downstream can support them... it's infectious. Really unfortunate that we haven't been able to move past this.
- martin_a 1y ago
  You can think about WordPress what you want, but afaik it does not allow to upload WebP files to its media gallery without any additional plugins while being said to run large parts of the internet...
  - celsoazevedo 1y ago
    Just tested on my self-hosted WordPress blog and it works without any plugins. WebP support was added to WordPress in 2021 with version 5.8: https://wordpress.org/documentation/wordpress-version/version-5-8/#adding-support-for-webp https://wordpress.org/documentation/wordpress-version/versio... AVIF support in 2024, with v6.5: https://make.wordpress.org/core/2024/02/23/wordpress-6-5-adds-avif-support/ https://make.wordpress.org/core/2024/02/23/wordpress-6-5-add...

bob1029 1y ago

Beyond the compression (which is amazing), JPEG is also extremely fast when implemented well. I'm not aware of any other image format that can encode at 60fps+ @ 1080p on a single CPU core. Only mild SIMD usage is required to achieve this. With dedicated hardware, the encode/decode cost quickly goes to zero. I struggle to understand the justification for other lossy image formats as our networks continue to get faster. From a computation standpoint, it is really hard to beat JPEG. I don't know if extra steps like intra-block spatial prediction are really worth it when we are now getting 100mbps to our smartphones on a typical day.

MrDOS 1y ago
https://news.ycombinator.com/item?id=44298656 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.
- bob1029 1y ago
  What is the likelihood of experiencing precisely marginal network conditions wherein webp improves the user experience so dramatically over jpeg that the user is able to notice? If jpeg is loading like ass, webp probably isn't going to arrive much faster.
  - MrDOS 1y ago
    I'm sorry, I misunderstood your doubt of the usefulness of other lossy formats as criticism of using lossy formats in general in the face of higher bandwidth. Reading too fast, never mind me... :)
- GuB-42 1y ago
  If you have slow internet on your smartphone, chances are that you also have a slow smartphone, and therefore decoding performance matter, it may also save you a bit of battery life for the same reason, which may be important in place with little internet coverage. You have to find a balance, and unless (still) pictures are at the center of what you are doing, it is typically only a fraction of the bandwidth (and a fraction of the processing power too). We are not talking about 100 Mbps, we downloaded JPEGs from dialup connections you know. You don't even need to go into the Mbps unless you are streaming MJPEG (and why would you do that?).

77pt77 1y ago

How come jpeg 2000 never became popular?

llm_nerd 1y ago
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.
- 77pt77 1y ago
  So like mjpeg but for jpeg 2000? That doesn't even make much sense because you lose inter-frame compressibility
  - meindnoch 1y ago
    Every frame is a keyframe in digital cinema. It's literally a bunch of JPEG2000 files, wrapped in an MXF container. A typical 2hr movie is in the 300-400GB ballpark.
AshleysBrain 1y ago
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.
SimplyUnknown 1y ago
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
Maken 1y ago
JPEG 2000 used to be a patent minefield.
1y ago

no_wizard 1y ago

EDIT: I was wrong, and had PNG and JPEG formats backward. As others correctly pointed out PNG is lossless where as JPEG is lossy. PNG is better for marketing / UI / artistic imagery and JPEG for photographs due to the tolerance for JPEGs lossy encoding with photographs, seems to be the generally accepted opinion now. Regardless, since the picture tag[0] was introduced I’ve used that for most image media by default with relevant fallbacks, with WebP as default. Also allows loading relevant sized images based on media query which is a nice bonus [0]: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/picture https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

Tobani 1y ago
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.
- kevingadd 1y ago
  PNGs are also ideal for color accuracy since one of the things you lose quickly when converting to JPEG is the ability to have an exact RGB value flow from input to output, even at a high quality level. So if you want i.e. a banner graphic to seamlessly blend in with your site's background color, JPEG is worse for that.
  - martin_a 1y ago
    Sorry, but that sounds more like a problem with your color management systems and workflows and not so much with JPEG itself.
    - kevingadd 1y ago
      JPEGs are intrinsically YCbCr not RGB, so I don't know how you would avoid some precision loss when you combine that colorspace conversion with things like the quality level and (potentially) subsampling.

jmyeet 1y ago

So there are two use cases for public image dissemination: 1. Lossy: JPEG fills this role; 2. Lossless: this was GIF but is now PNG; and 3. Animated: GIF. So for a format to replace JPEG, it must bring something to the table for lossy compression. Now that JPEG is patent-free, any new format must be similarly unencumbered. And it's a real chicken-and-egg problem in getting support on platforms such that people will start using it. I remember a similar thing happening with Youtube adding VP9 (IIRC) support as an alternate to H264, which required an MPAA patent license. The MPAA also tried to cloud VP9 by saying it infringed on their patents anyway. No idea if that's true or not but nobody wants that uncertainty. Anyway, without total support for VP9 (which Apple devices didn't have, for example) Youtube would need to double their storage space required for videos by having both codecs. That's really hard to justify. Same goes for images. You then need to detect and use a supported image format... or just use JPEG.

greenavocado 1y ago

DO NOT USE WEBP JPEG-XL is the superior format. The only reason WebP exists is not because of natural selection, but because of nepotism (Google Chrome). https://www.reddit.com/r/AV1/comments/ju18pz/generation_loss_comparing_jpeg_webp_jxl_and_avif/ https://www.reddit.com/r/AV1/comments/ju18pz/generation_loss...

dragonwriter 1y ago
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?
- Spivak 1y ago
  I mean if you define superior not in terms of its technical merits but because of its blessed status by Google. It's not a terrible format but it is very much "what is the worst quality we can reasonably get away with to save on bandwidth." Such a thing does have its uses. At some point you have to be pragmatic and meet users where they are but doesn't mean you have to like that Google did throw their weight around in a way that only they really can.
  - dragonwriter 1y ago
    > I mean if you define superior not in terms of its technical merits “Technical merits” are rarely, for anything, the sole measurement of fitness for purposes. Even for purely internal uses, internal social, cultural, and non-technical business constraints often have a real impact on what is the best choice, and when you get out into wider uses with external uses, the non-technical factors proliferate. That's just reality. I understand the aesthetic preference to have decisions only require considering a narrow set of technical criteria which you think should be important, but you will make suboptimal decisions in the vast majority of real-world circumstances if you pretend that the actual decision before you conforms to that aesthetic ideal.
- Zardoz84 1y ago
  just fuking use a poly fill to add support of JPEG XL. Or store JPEG XL and convert on the fly to JPEG to supply it to browsers that don't support JPEG XL.

JacobiX 1y ago

I loved the article, but it overlooks one important point: although the JPEG format is frozen, encoders are still evolving ! Advances such as smarter quantization, better perceptual models, and higher-precision maths enables us achieve higher compression ratios while sticking to a format that's supported everywhere :)

edflsafoiewq 1y ago
I guess you're thinking of jpegli? Do you know how big a difference this actually makes?
- ksec 1y ago
  Anywhere from 5-15% if I remember correctly depending on source material. I was at one point thinking this would make JPEG-XL and AV1F moot because all of a sudden JPEG became good enough again. But the Author of JPEG-XL suggest there is still so much JPEG-XL encoder can do to further optimise bit / quality especially in the bpp below 1.0 range.
- JacobiX 1y ago
  MozJPEG, Guetzli and also Jpegli
- qingcharles 1y ago
  Jpegli is designed from the ashes of JPEG-XL (same author), both from Google. IIRC he also had a hand in the PNG format?
cogman10 1y ago
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.

imageformatssux 1y ago

How in the world do people store images / photos nowadays? 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. JPEG is... old, and it shows. The filesizes are a bit bloated, which isn't really a huge problem with modern storage, but the quality isn't great. 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?) HEIC is good, as long as you pinky promise to never ever leave Apple's ecosystem, ie HEIC sucks. AVIF seems computationally expensive and the support is pretty spotty - 8bit yuv420 might work, but 10b or yuv444 often doesn't. Windows 10 also chokes pretty hard on it. Alternatives like WebP might be good for browsers but are nigh-unworkable on desktops, support is very spotty. PNG is cheap and support is ubiquitous but filesizes become sky-high very quick. 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. Is jpeg still the only good option? Or is encoding everything in jpeg-xl or avif + praying things get better in the future a reasonable bet?

SAI_Peregrinus 1y ago
I store Raw + PSD with edits/history + whatever edited output format(s) I used.
tristor 1y ago
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.
- Zardoz84 1y ago
  There is NO quality loss when converting from JPEG XL to JPEG and vice versa. It was done by design. Not an accident.

legitster 1y ago

This takes me back to when the goal of a webpage was to be less than 1Mb. At the time, the only reason to use PNG (such luxury) was when you needed transparency. The variable compression of JPEG was very important. In Photoshop you could just grab an image and choose the file size you needed and the JPEG quality would degrade to match your design constraints.

deleted 1y ago

[deleted]

politelemon 1y ago

The last part of the article about jpeg being outpaced seems anecdotal or unsubstantiated, it needs context.

hungryhobbit 1y ago

I love how the article implies there's something flawed about webp at the end ... but if you click the link the only "flaw" reported is that webp isn't ubiquitous enough yet, so some sites don't support it Perfect logic: let's not switch to webp because it's bad. Why is it bad? Not everyone has switched to it yet.

msabalau 1y ago
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.
- mr_toad 1y ago
  > a wide range of ways. I hear this all the time but I have yet to encounter it. Is it just social media and lolcats? Maybe the software I’m using is too uncool to not support it.
frollogaston 1y ago
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.
Lammy 1y ago
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-41064 - https://nvd.nist.gov/vuln/detail/CVE-2023-41061 https://nvd.nist.gov/vuln/detail/CVE-2023-41061 - https://nvd.nist.gov/vuln/detail/CVE-2023-4863 https://nvd.nist.gov/vuln/detail/CVE-2023-4863 - https://citizenlab.ca/2023/09/blastpass-nso-group-iphone-zero-click-zero-day-exploit-captured-in-the-wild/ https://citizenlab.ca/2023/09/blastpass-nso-group-iphone-zer...

ksec 1y ago

I want to add a slightly off topic point here. This submission was originally shown as [dead]. I have no idea why, I read some of the content and seems decent enough, especially in the current state of things when JPEG-XL is blocked because of AOM / Google Chrome. I vouched for it and upvoted, then somehow it is on the front page. I wonder if dead means somehow flagged it. If so, then why? If not, why is it dead?

carlosjobim 1y ago
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.
- encom 1y ago
  Flagging seems to be used like a super downvote on both submissions and comments. Admins appear okay with it.

martin_a 1y ago

As others have pointed out, JPEG is just fine. It's "enough" in the best sense of the word and gets its job done. It's supported on every device, in every browser, image viewer and whatnot. It. Just. Works. Maybe there are formats that compress better or lossless, but thanks to advancements in disk space and transfer rates (I know, not everywhere but penetration and improvement will happen...) the disadvantages of JPEG can be handled and we can just enjoy a very simple file format. In an era where enshitification lingers around every corner I'm just happy that I don't need to think about whether I have to convert _every digital picture I've ever taken_ into some next-gen format because some license runs out or whatnot. It just works. Let's enjoy that and hope it sticks around for 30 more years.

poisonborz 1y ago

The actual issue is that this is not an issue for the users. Only global providers, so they were the ones pushing "obscure" solutions. Music fidelity was more of a consumer problem, so formats like FLAC found a foothold besides the go-to one.

t1234s 1y ago

I notice webp produces images about 20% smaller than mozilla jpeg while appearing slightly sharper. I use a <picture> element to offer webp versions first but always include jpeg versions for future-proofing.

wolf550e 1y ago

The reason JPEGs still rule is because Google Chrome removed support for JPEG-XL, the actually better photo format, because the Google guys who did AVIF decided they don't want competition.

ethan_smith 1y ago
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.

modeless 1y ago

The amazing thing about JPEG is people are still squeezing out backwards compatible compression improvements 30 years later. Mozjpeg is well known by now, but Jpegli was just published last year and does even better at high bitrates[1]. It's hard to want to adopt newer formats when they keep getting squeezed by further improvements to good old JPEG. [1] https://opensource.googleblog.com/2024/04/introducing-jpegli-new-jpeg-coding-library.html https://opensource.googleblog.com/2024/04/introducing-jpegli...

bonoboTP 1y ago
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/123650307.pdf 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

shmerl 1y ago

I'm trying to replace jpeg with avif in my use cases, but some sites still don't handle avif. Even Github! Though the latter doesn't support IPv6 either.

lucgommans 1y ago

> It’s been difficult to remove [old JPEG] from its perch. [...] the formats AVIF and HEIC, each developed by standards bodies, have largely outpaced [JPEG] I'm currently sticking to JPEG because, last time I tried, JPEG came out as the best format. Referencing my memory at https://chaos.social/@luc/113615076328300784 https://chaos.social/@luc/113615076328300784 - JPEG has two advantages on slow connections: the dimensions are either stored up front so the layout doesn't jump, or maybe the renderer is better; and it loads a less-sharp version first and progressively gets sharper - JPEG was way faster when compressing and decompressing - on the particular photo I wanted to optimise in this instance, JPEG was also simply the best quality for a given filesize which really surprised me after 32 years of potential innovation Regarding AVIF, my n=1 experience was that it "makes smooth gradients where jpeg degrades to blotchy pixels, but at decent quality levels, jpeg preserves the grain that makes the photo look real". Gradients instead of ugliness at really small sizes can be perfect for your use-case, but note that it's also ~80 times slower at compression (80s vs. <1s) JpegXL isn't widely in browsers yet so I couldn't use it > These days, the [JPEG] format is similar to MP3 The difference with mp3 is that Opus is either a bit better or much better, but it's always noticeably better. You can save ~half the storage space. For speech (audio books) I use 40kbps, and for music maybe 128kbps which is probably overkill. And I delete the originals without even checking anymore if it really sounds the same, I noticed that I simply can't tell the original apart in a blind test, no matter what expensive headset setup I try TFA attributes it to a simple "they were first" advantage, but I think this is why "Why JPEGs still rule the web": no file format is better than JPEG in the same way as Opus is better than MP3; in that you don't have to think about it anymore and it's always a win in either filesize or quality That said, Opus is also annoyingly hard to get into people's minds, but I've done it and you also see major platforms from compress-once-serve-continuously video (e.g. Youtube) to VoIP (e.g. Whatsapp) switching over for all their audio applications

GuB-42 1y ago

Because JPEG just works. It is not the best by far, but everybody supports it, and it is usually not worth saving a few bytes in exchange for worse support, added complexity and extra processing. Lossy compressed images are usually not the most significant consumers of bandwidth and disk space. Videos are. That's why there have been a lot more focus on video formats than anything else, there is a lot to gain here, not so much with still images. JPEG-XL is super-complicated because it supports plenty of things most people don't really need. Webp is somewhat better supported because it is backed by Google, it is also what is essentially a single frame video, so if you did the hard work on video (where it matters), you get images almost for free, and it saves Google a tiny bit of bandwidth, and "a tiny bit" is huge at Google scale. We are seeing the same thing with audio. MP3 (1991) is still extremely popular, the rest is mostly M4A/AAC (2001). We pretty much have had the perfect audio format now, which is Opus (2012) and yet, we don't even use it that much, because the others are good enough for what we make of them.

Gigachad 1y ago
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.
- maeln 1y ago
  It also is used in video games. OGG/Libvorbis was already pretty popular (probably because it was free of patent), and opus has seen some use.
RadiozRadioz 1y ago
Opus is too complex. IIRC there is only one full implementation.

neuroelectron 1y ago

I think it's about time we switched from JPEGs to Rust.

karim79 1y ago

I've no single clue as to the future of image formats. All or them (or almost) have merits and stuff they suck at. I've been building a service which makes no judgement about it but tries to provide all the choices. JXL will be added soon: https://kraken.io https://kraken.io

cadamsdotcom 1y ago

“Because it has a 30 year head start. And there are better, new, formats coming all the time; but everyone supporting them hates each other.”

tsoukase 1y ago

There are only two kinds of image file formats: the ones people complain about and the ones nobody uses.

userbinator 1y ago

I have written a JPEG, GIF, and PNG decoder. All easily weekend projects. As for the other two I've attempted the same for: JPEG2000: insanely complex and nonintuitive, especially the edge-cases and overly flexible encoding decisions WebP: also complex, and effectively Google-proprietary

panja 1y ago
Thoughts on jxl?
NooneAtAll3 1y ago
have you tried QOI? ;)

hoseja 1y ago

There is an photo example for quality levels throughout the article but instead of classical JPEG compression artifacts it just seems to get progressively more posterized. What's up with that.

carra 1y ago

We keep hearing different variants of "webp should take over because now it has good browser support". But that is not nearly enough for an image format to reach widespread adoption. People want to be able to open the images anywhere (what about watching photos in a smartTV? or an old tablet? what about digital picture frames?). They want to edit the images in any program (what about this FOSS editor? what about the many people stuck in pre-subscription Photoshop versions?). They also want to ensure far future access to their precious photos, when formats like JPEG2000 or even WebP might be long gone. I mean, webp was made by Google and we know how many of their heavily promoted creations are dead already...

whyever 1y ago
> 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.
- carra 1y ago
  Fair enough. What I meant by this is that, in the end, most software that decides to add webp support is doing it because of the huge push by Google to do so. But if they suddenly change that push to something else then webp might find itself growing more irrelevant.
  - nottorp 1y ago
    I didn't know webp was pushed by Google. They should publicize that fact more so people know to avoid the format entirely. What Google pushes is in their self interest and has nothing to do with the good of the unwashed masses.
    - graealex 1y ago
      WebP is basically a single i-frame from the WebM video codec, which literally was developed by Google to avoid paying license cost for H.264. For which they had great incentive. WebP is to WebM what HEIC is to HEVC. You can argue that using free codecs is a collateral benefit here, even though Google did it for selfish reasons. It is not detrimental to the public or the internet.

scrapheap 1y ago

I'm sure that I'm not the only person here being reminded by this that over 30 years ago they were being amazed by viewing JPEGs on their Amiga using HAM mode...

alex77456 1y ago

I'm surprised some multi-encoder container format didn't take over by now, seeing as there is no one size fits all clear winner so far.

suspended_state 1y ago

It's the VHS of digital image compression and storage.

Blahagun 1y ago

Of course there are tons of better formats than JPEG but it needs to be understood that the most important feature of JPEG is to be exchangeable. It doesn't matter what your shiny new web browser supports, JPEG is considered supported everywhere and all editorials actually refuse to accept anything other than JPEG. You can't just break everyone's workflow because Google decided to force WebP (for purely selfish reasons, of course). The web browser is actually one of the least important platforms for JPEG. To day JPEG still executes its mission perfectly and with huge bandwidth increases it doesn't even matter how large the file is.

hulitu 1y ago
> Of course there are tons of better formats than JPEG and webp is not one of them.
dingdingdang 1y ago
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 https://siipo.la/blog/is-webp-really-better-than-jpeg edit: https://opensource.googleblog.com/2024/04/introducing-jpegli-new-jpeg-coding-library.html 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!
sumtechguy 1y ago
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.
- wongarsu 1y ago
  It helps that in most cases when people make a zip the compression is a secondary feature. What people want 90% of the time is a container format to put multiple files or a whole folder structure into one file. .zip or .tar.gz do this just fine, even if their compression factor and speed aren't that great by modern standards. Same with jpeg: Most people want to just encode images, reducing file size by 10% is a negligible win for most people

nottorp 1y ago

> Thirty-eight years later, we’re still using the GIF—but it never rose to the same prevalence of JPEG. > The GIF was a de facto standard. The JPEG was an actual one I know this is IEEE but seriously? JPEG won because it was a formal standard? Didn't JPEG win because it supported more than 256 colours and, with the lossy compression, greatly reduced file size and bandwidth needs for our cat photo and porn collections? While proposed replacements ... solve what problems?

RugnirViking 1y ago

The single biggest things that could be done to remedy this in order 1) snipping/clipping/screenshot tool outputs webp 2) convert to webp on ctrl-c ctrl-v from browsers 3) whatsapp/messenger/discord support. People will say these work fine, in my experience its a gamble, which is shouldn't be. It should be seamless, literally no edge cases

whizzter 1y ago

While the article is mostly good one glaring technical error annoys me. "The stronger the cosine transformation, the more compressed the final result" is simply wrong. DCT (and the inverse DCT) are transforms that transform between "sample" and "frequency" domains, it's well defined should be perfectly reversible without compression (iirc the one in JPEG should be lossless given as many bits as the samples themselves). The trick of DCT based compression is that humans don't notice when information disappears from higher frequencies(also in _natural images_ there is often little data in high frequencies, often lots of 0 that can be immediately cut). So harder compression means removing more high frequency data from storage without it being too noticeable when reconstructing samples from the frequency domain at decompression. Conversly however, if you have "sharp edges" in the sample data you need more higher frequencies to reproduce the sharp edges without "ringing" artefacts (this is why you will see noisy blocks around text in highly compressed JPEG's with text since it runs out of bandwidth to adjust). The frequency domain values, and how compression affects removing various frequencies(black and white in the filter images) can be illustrated on the wikipedia filter comparsion example image below. (low frequencies are in the upper-left corner of the filter and spectrum images whilst higher frequencies horizontally are to the right and higher vertical frequencies are towards the bottom). https://en.wikipedia.org/wiki/File:DCT_filter_comparison.png https://en.wikipedia.org/wiki/File:DCT_filter_comparison.png https://en.wikipedia.org/wiki/Discrete_cosine_transform https://en.wikipedia.org/wiki/Discrete_cosine_transform (Mainly "Example of IDCT" section towards the bottom but also the preceding ones).

donatj 1y ago

We started using AVIFs recently in picture elements with fallback to JPEG, and I'm a pretty big fan. The compression is good, the tooling is decent. They're supported by most things natively. Browser support for AVIF is nearly good enough that you might not need the fallback in reality. The only real problem I have encountered is that animated AVIFs are super stuttery in Safari for some reason.

dev1ycan 1y ago

JPEG-XL on Chrome is a perfect example of why Google should have Chrome taken away from it.

einpoklum 1y ago

> These days, the format is similar to MP3 or ZIP files—two legacy formats too popular and widely used to kill. Are MP3's not dying out gradually, like, say, WAVs have? I mean, do people/organizations actually encode anything to MP3 rather than AAC, these days?