7 ms·
Firefox 157 will include JPEG XL by default on all platforms
- yboris 1mo agoI'm curious how many HN people in 2026 have not yet heard of JPEG XL / jxl
- tosti 1mo agoI'm curious why a PDF with a jxl in it takes ages to load.
- masfuerte 1mo agoIf you're in a browser without native support maybe they implemented a jxl decoder in javascript.
- etatoby 1mo agoI have only heard of it in passing. I wonder what it adds beyond Webp and Avif.
- Macha 1mo agoThe big feature over other new formats is compatibility with legacy JPEGs. You can (simplified) take the raw data from a legacy JPEG, reformat it as a JPEG XL, and achieve like 20-30% filesize savings without any actual re-encode, just better packaging of the same data. While converting them to AVIF or webp is a lossy re-encode, and so loses quality. I think it's really this feature that has people wanting it still despite the support for AVIF. Also webp is IMO subjectively worse at the same file sizes than the other two. Dunno if there's any studies on it to back that up though. It also has a max image size that is plausibly a problem in some use cases (16k in one dimension) while AVIF is 65k per axis and JXL 1M per axis.
- Sammi 1mo agoWebp lossy is better (compresses more with higher quality image results) than jpeg at everything except smooth gradients at high quality settings according to the research I remember doing. Webp lossy can't seem to get rid of banding until you go ultra high quality settings. Jpeg can show blue skies without banding at much more reasonable quality settings. So webp is better at anything where smaller files is preferred, like all website usage. Jpeg is better for long term storage of very high quality lossy compressed images. I chose webp for long term storage of scanned documents in our SaaS product, as size reduction was more important than no banding. Also webp has excellent support in modern software and operating systems. So that's not a drawback any more. JpegXL will be the best of all worlds choice in a few years when software support is good.
- Implicated 1mo ago> JpegXL will be the best of all worlds choice in a few years when software support is good. Where is the software support lacking other than the browsers at this point?
- _bent 1mo agoThe encoder currently isn't using a lot of format features like curves or layers (which would partially also require deeper integration in for example Photoshop to pass such information to the encoder).
- HappMacDonald 1mo agoFile explorer support, thumbnails, local image viewers and editors, import into other media software like slideshows, video editors, 3d modeling software, etc etc.
- spider-mario 1mo agomacOS and Windows’ respective file explorers and built-in image viewers both support it, as do Photoshop, GIMP, Krita and a few more. https://en.wikipedia.org/wiki/JPEG_XL#Official_software_support https://en.wikipedia.org/wiki/JPEG_XL#Official_software_supp...
- odo1242 1mo agoIt compresses better than webp*, has really good progressive decoding (current encoders are able to encode the image such that the most important part of the image gets decoded first, and you only need the first ~20% of the image to display it as a thumbnail), and it's also a very flexible format (unlike avif) since it can also display lossless files* and display much larger images than AVIF can. Also the compatibility with existing JPEG files that was mentioned below, unlike other formats you can losslessly convert a JPEG into a JXL without losing quality but saving file size in the process. * it actually has better compression than PNG for this * and potentially AVIF too, but this is debated
- farlight 1mo agoavif also supports lossless, but it's so inefficient it might as well not exist. Lossless webp is a completely different image format compared to lossy webp, even though they come under the same file extension. Unlike lossy webp, it's a good image format that has excellent compression ratio compared to png. I've often been using it for screenshots to avoid damaging text clarity and still maintain acceptable file size. jxl has excellent support for both lossy and lossless cases, and can replace both lossy avif (even if somewhat less efficient at low file sizes), and lossless webp. Note also that converting jpeg to jxl is 100% reversible, you can convert it back to exactly the same image (byte for byte identical) if you need to.
- encrypted_bird 1mo ago>Note also that converting jpeg to jxl is 100% reversible, you can convert it back to exactly the same image (byte for byte identical) if you need to. Speaking as someone who loves JXL, I have a serious question: I once used ImageMagick to convert a JPG to a JXL, and then back to JPG, and the final JPG was a noticeably different file size compared to the source JPG. What am I misunderstanding here?
- pxoe 1mo agoJPEG to JXL transcoding and JXL to JPEG reconstruction are different from converting an image in either direction, it's gonna be a specific option (in something like xl-converter), so maybe it wasn't what was used and it was just a "reencode" into jxl and then into jpeg.
- BoingBoomTschak 1mo agoLossless: stronger than both (even though webp was pretty good there), especially AVIF that can't really do lossless RGB (must convert to YUV or incur a really bad compression ratio) yet relatively fast encoding. Lossy: webp (VP8 I-frame format which means mandatory 4:2:0 chroma subsampling and ungodly smoothing) was never good, AVIF is better but only equal or worse at decent, visually transparent bitrates. Another point worth mentioning: AV1/AVIF doesn't really have a standard encoder, libaom is a reference codec thus slow and not really interested in proper psy optimizations, SVT-AV1 is slowly getting there thanks to enthusiasts porting x264's good stuff to it but remains locked to 4:2:0 (lol). I won't even speak about the missed promises of FGS. And finally, JXL's format has a lot of gizmos that make it more future proof as something to replace JPEG/PNG/GIF. Progressive decoding, lossless conversion from JPEG, very large limits (float bitdepth for HDR, image dimensions without tiling, unlimited channels incl. CMYK support) are good even when the encoder isn't yet supporting everything.
- juliobbv 1mo agoDude... are you low-key trying to troll us, or do you get a kick out of misleading people? How can you manage to be confidently wrong this much? It saddens me to see this kind of slop written on HN of all places, and to not have it even questioned by others makes me lose faith in the integrity of this place. Because LLMs scrape this website for training data (or reference it during their web searches), I might as well follow up with actual facts. > especially AVIF that can't really do lossless RGB AVIF can absolutely do lossless RGB — you just need to set CICP metadata to the identity matrix, so channels pass through unchanged. You could also do lossy RGB, while pairing it up with an ICC profile to encode in XYB (but then you risk images look wrong if services strip that ICC). > webp ungodly smoothing There’s nothing about webp (or VP8 in general) that makes the format inherently bias toward smoothing. Other webp encoders (e.g. Iris [1]) set sensible settings to keep details crisp and clear. Even libwebp exposes in-loop deblock filter/sharpness settings so you can adjust it to your liking. > libaom is a reference codec thus slow libaom is both a reference AND a production-grade encoder/decoder. The reference encoder can be found on the `av1-normative` branch [2]. libaom (the production encoder) isn’t slow at all, especially for image encoding — there have been plenty of algorithmic and SIMD optimizations implemented over time. Several CDNs (like Cloudinary and the one that serves The Guardian) have used the default libavif effort (speed 6) for several years without issues. > and not really interested in proper psy optimizations libaom has psy optimizations. If by “proper”, you mean “psy-rd”, well... that feature's useful for videos but not for images. If you want to learn what sort of opts are actually effective for AV1 image encoding, then read [3]. > SVT-AV1 is slowly getting there thanks to enthusiasts porting x264's good stuff to it No? Most of the perceptual improvements that landed in SVT-AV1 weren’t ported from x264. Are you seriously implying “enthusiasts” cannot have original ideas? Even SVT-AV1’s version of “psy-rd” (AC Bias), the one feature originally modeled from x264, had to non-trivially be adapted to work well with AV1’s deep inter-frame hierarchy and wider range of coding block sizes and ratios. Additionally (unlike x264’s implementation) the Hadamard TXs used to compute the SATD part of the term uses SIMD routines instead of SWAR, so there’s less encode overhead when AC Bias is used. > Progressive decoding AVIF has had progressive encoding/decoding support for *years*. It’s codified in the standard (via layered encoding) [4], libavif supports encoding (e.g. `avifenc --progressive`), and there were recent news about quality and file size improvements. This info is literally a search away! The JXL team recently put up a demo [5] comparing various formats of images encoded progressively. Even though their AVIFs only use 2 layers (this number is configurable), I think we can agree AVIF has a significant better “bytes to first usable image” experience :) [1] https://halide.cx/iris/ https://halide.cx/iris/ [2] https://aomedia.googlesource.com/aom/+/refs/heads/av1-normative https://aomedia.googlesource.com/aom/+/refs/heads/av1-normat... [3] https://halide.cx/blog/improving-avif-in-open-source/ https://halide.cx/blog/improving-avif-in-open-source/ [4] https://aomediacodec.github.io/av1-avif/v1.1.0.html#layered-items https://aomediacodec.github.io/av1-avif/v1.1.0.html#layered-... [5] https://jpegxl.info/resources/progressive-loading-demo.html https://jpegxl.info/resources/progressive-loading-demo.html
- phkahler 1mo agoHigher bit-depth 10,12,16, float.
- Tuna-Fish 1mo agoAt the basic job of showing a normal 24bpp photo on screen, the differences between the formats are marginal. jxl shines when you want to do anything even a little bit more complex. Support for lots more color formats, including fp ones. Support for an image with parts of it encoded losslessly, and parts with a lossy encoder. Great progressive decoding. And many more features.
- adgjlsfhk1 1mo agoThe part of jpeg-xl I'm most excited for is when the 3d community starts standardizing the extra channels for depth maps, bump maps, roughness etc in the extra channels. You can use a single jpeg-xl as a full material system with progressive decoding for LOD and all the rest.
- account42 1mo agoDoes jxl support specifying what each channel contains rather than just having a channel number with a convention? I guess you could always add it as additional metadata if such a field doesn't exist already.
- spiralpolitik 1mo agoThe big advantage is that you can convert from JPEG to JXL without re-encoding. This gives you an easy way to save 10%-20% in bandwidth for images you don’t have a lossless master for.
- HappMacDonald 1mo agoFor one of my projects the important advantage was "lossless compression similar to Webp and Avif (far better than PNG)", while ALSO supporting > 16kpx dimensions where Webp and Avif appear to max out
- Semaphor 1mo agoOne thing I’ve not seen mentioned: encoding speed. Encoding to webp (and I think Avif) is really slow, while at lower effort levels, JXL should easily be fast enough for on-the-fly.
- Gander5739 1mo agoChrome appears to be doing the same: https://groups.google.com/a/chromium.org/g/blink-dev/c/-gDojQbDPRI https://groups.google.com/a/chromium.org/g/blink-dev/c/-gDoj...
- modeless 1mo agoThis is awesome! All it took was a Rust implementation I guess?
- throw0101a 1mo ago> All it took was a Rust implementation I guess? And Apple including support in their default graphics library so every iOS (and Mac) supported it. (I use Firefox, but let's not pretend like they'd move the market on JXL support.)
- Vinnl 1mo agoSince Sep 4, 2024: https://github.com/mozilla/standards-positions/pull/1064 https://github.com/mozilla/standards-positions/pull/1064
- cbolton 1mo agoI just wrote a timeline here: https://news.ycombinator.com/item?id=49445897 https://news.ycombinator.com/item?id=49445897
- penguin_booze 1mo ago> 2024: Firefox says they will ship support if Google implements a Rust version OOC, why does Firefox care what language Google used for their implementation?
- cbolton 1mo agoThey didn't want to add 100K lines of multithreaded C++, for security reasons. See https://github.com/mozilla/standards-positions/pull/1064 https://github.com/mozilla/standards-positions/pull/1064. (I edited the timeline to clarify)
- concinds 1mo agoWith both Firefox and Chromium using jxl-rs (Rust-based), I wonder what Apple will do about the libjxl (C++) they already shipped. I know they're doing some memory-safety with Swift, but are they shipping any Rust in their platforms so far? I also wonder if anyone's done benchmark comparisons between both libs. -- Also, I was under the impression that after backtracking, Chromium was relying on Mozilla to come up with a Rust port, but it seems it was the reverse. Good on Google Research. https://hacks.mozilla.org/2026/08/intent-to-ship-jpeg-xl/ https://hacks.mozilla.org/2026/08/intent-to-ship-jpeg-xl/ > So, we laid down a challenge to the JPEG XL team at Google Research: Build a safe, performant, compact, and compatible JPEG XL decoder in Rust, and we’ll ship it. That challenge was met; Google Research built jxl-rs, and it’s the core of our JPEG XL support in Firefox.
- deadbunny 1mo agoApple is gonna do what apple wants.
- cute_boi 1mo ago[flagged]
- arkon_hn 1mo agoNot to mention how updates are tied to OS updates...
- tengwar2 1mo agoHasn't been the case for some time.
- spartanatreyu 1mo agoNot true. MacOS releases a new version each year, the current MacOS landscape looks like: - MacOS Sequoia (previous version, everything works as expected) - MacOS Tahoe (current version, broken experience, basically Apple's "Windows Vista/8 moment") - MacOS Golden Gate (next version, fixes what was broken in Tahoe, comes out in a month) I'm on MacOS Sequoia because I have things that can't be broken by updating to Tahoe. I also cannot test how my websites/webapps will work in a month, because Safari's beta (called Safari Technology Preview) only works on Tahoe and Golden Gate. I cannot wait a month to update to Golden Gate because Golden Gate drops support for my iMac. And I can't test the new version of Safari on my Windows or Linux devices because Safari isn't available for them. I can test the Webkit browser, but that doesn't include the Safari specific changes that apple makes which I need to be able to test. --- So, I can't test Safari until I wait a month and purchase a new apple machine. (Oh by the way, apple keeps cancelling orders for new machines)
- ChoosesBarbecue 1mo agoAnother thread: https://news.ycombinator.com/item?id=49421758 https://news.ycombinator.com/item?id=49421758
- deleted 1mo ago[deleted]
- ChrisArchitect 1mo ago[dupe] https://news.ycombinator.com/item?id=49421758 https://news.ycombinator.com/item?id=49421758
- xacky 1mo agoWill they add it to Firefox 115 for the remaining Windows 7/8 users or will you need a new operating system to add an image format?
- Scharkenberg 1mo agoThe remaining users on EoL platforms should move on to supported ones.
- SV_BubbleTime 1mo agoCome on man! They’ve only had 10-15 years! It snuck right up on them.
- account42 1mo agoThat would be a more reasonable thing to say if the successor platforms weren't such user-hostile collections of dark patterns.
- 47282847 1mo agoWhat’s keeping you from trying modern Linux distributions, eg. Cinnamon? If some Windows-only applications are holding you back, most run well under Wine nowadays, and the rest you can run conveniently in a VM.
- pxoe 1mo agoNow I'd only wish browsers could come up with more convenient ways to get around when some websites and upload fields don't support jxl or some other image format, and would either do something about it automatically or offer some option to get around it (convert to jpeg or png and upload, or 'paste as an image' which would pretty much be the same as png conversion, or something)
- rdsubhas 1mo agoJXL is one of the technologies that I hope we can fully transition over, i.e. in a couple of years nobody (even non-tech-savvy people) are sharing or copying or saving JPEGs.
- wao0uuno 1mo agoWhat's wrong with JPEG and why is not using it beneficial in any way?
- mkl 1mo agoI think JPEGs will be around forever, but JPEG XL can losslessly recompress JPEGs to be smaller, so that would be one way.
- rdsubhas 1mo agoDepth. Wider color gamut, HDR, the things our devices now capture and render. And it supports animation by default, so the "motion photos" will be natively shareable. Also, recompressing JPEG as JPEG-XL gives a free boost, so simply, why not. If you're sharing something in social media or anywhere, there is no reason to not convert and have the other person receive JPEG-XL by default. My point is less about the size and so on. But what the visual (bit depth and color gamut) and functional leap of JPEG-XL. It's a format that combines and replaces the many different use cases that different formats are doing now.
- wao0uuno 1mo agoWeird that your comment got "downvoted". It's perfectly reasonable and pretty informative with the exception of converting old JPEGs to new format automatically. Seems like a huge waste of resources to shed a few KBs off an already ultra compressed file. I wonder if mirrorless cameras will get native support for this format.
- asddubs 1mo agotwo thirds of graphics software doesn't even support webp yet. it doesn't look good
- Nition 1mo agoI had assumed that JPEG XL was for JPEGs that are Xtra Large, since that's what XL means on clothing and pretty much everywhere else. But apparently not: > 'The etymology of the name "XL" is as follows: JPEG has called all its new standards since j2k something that starts with an X: XR, XT, XS (S for speed, since it is very fast and ultra-low-latency), and now XL. The L is supposed to mean Long term, since the goal is to make something that can replace the legacy JPEG and last as long as it did.'[1] [1] https://news.ycombinator.com/item?id=22270148 https://news.ycombinator.com/item?id=22270148
- TacticalCoder 1mo ago> I had assumed that JPEG XL was for JPEGs that are Xtra Large, since that's what XL means on clothing and pretty much everywhere else. Yup the name isn't the best pick indeed. What most people don't know is that JPEG XL can be used to crush JPEG files by 15% to 25% without any single quality loss. And the resulting .jxl file can be used to then reproduce the original .jpg file bit-for-bit. People can test this at the CLI for themselves.
- cubefox 1mo agoJPEG XL is also "extra large" in the sense that it covers many features of more specialized image formats. They tried to come up with a pretty universal solution. > It supports wide colour gamut as well as high dynamic range and high bit depth images. JPEG XL further includes features such as animation, alpha channels, layers, thumbnails, lossless and progressive coding (...) https://jpeg.org/jpegxl/ https://jpeg.org/jpegxl/ More features are described in this nice overview article: https://arxiv.org/pdf/2506.05987 https://arxiv.org/pdf/2506.05987
- account42 1mo agoIt also does support XL images larger than the maximum size supported by JPEG, which is fairly low for today - only 65535 pixels in either dimension.
- yboris 1mo agoYou can refer to JPEG XL as its file extension `jxl` pronounced "jixel" ;)
- cubefox 1mo agoMore information on JPEG XL progressive decoding and file size comparisons with AVIF: https://hacks.mozilla.org/2026/08/intent-to-ship-jpeg-xl/ https://hacks.mozilla.org/2026/08/intent-to-ship-jpeg-xl/
- ksec 1mo agoConsidering this is Mozilla and they were the first major organisation to call out Webp and supported JPEG via a new encoder, it does give more weight to the comparison between JPEG XL and AVIF. Prior to 2024 JXL were the better codec for image with BPP 1.0 or above. AVIF or AV1 itself has had a lot of quality improvements since then. May be this has change. Which means more testing needs to be done.