Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
Chrome Graphics Google

Google Revisits JPEG XL in Chromium After Earlier Removal (windowsreport.com) 25

"Three years ago, Google removed JPEG XL support from Chrome, stating there wasn't enough interest at the time," writes the blog Windows Report. "That position has now changed." In a recent note to developers, a Chrome team representative confirmed that work has restarted to bring JPEG XL to Chromium and said Google "would ship it in Chrome" once long-term maintenance and the usual launch requirements are met.

The team explained that other platforms moved ahead. Safari supports JPEG XL, and Windows 11 users can add native support through an image extension from Microsoft Store. The format is also confirmed for use in PDF documents. There has been continuous demand from developers and users who ask for its return.

Before Google ships the feature in Chrome, the company wants the integration to be secure and supported over time. A developer has submitted new code that reintroduces JPEG XL to Chromium. This version is marked as feature complete. The developer said it also "includes animation support," which earlier implementations did not offer.

Google Revisits JPEG XL in Chromium After Earlier Removal

Comments Filter:
  • Can't Help But Think (Score:5, Interesting)

    by organgtool ( 966989 ) on Sunday November 23, 2025 @04:40PM (#65814007)
    I can't help but think that Google's decision to abandon JPEG XL was based, at least in part, on the development of their own image format: WebP. I can only assume that their reversal on JPEG XL means that their plans for WebP haven't been as successful as they had hoped. In any event, this is good for competition among image formats.
    • JPEG XL was also an image format Google worked on.

    • by ls671 ( 1122017 )

      Well, I guess it's nice to support JPEG XL if you want to access an online photo album or something like that using that format but for website development, I'd stick to more conventional image formats anyway to make sure it is supported by a variety of browsers.

      • by allo ( 1728082 )

        Google and others use a CDN for that. The URL says .jpg (or whatever the source format is) and the CDN sends the cheapest format your browser supports. Just open some of these "jpg" in a new tab and look how the title says "WebP image".

    • by bill_mcgonigle ( 4333 ) * on Sunday November 23, 2025 @05:23PM (#65814081) Homepage Journal

      JPEGXL really does everything webp does and so much more, and it's well thought out.

      WebP isn't terrible; they are smaller than I would have guessed given that they have the container overhead, but there's no stunning argument for it. "Better than PNG for what we used PNG for." OK, true, but.

      Google should just let AV1 be AV1 and focus on pushing HEVC out of the market with it. The real opponents of progress have left the image space and are mucking around with video and VR now. Google has the capability to do something about this and foster innovation.

    • It wasn't even webP, but a different standard entirely called UltraHDR image format [android.com] that just used JPEGs with a "gain map" that they rolled out to like, Instagram through a partnership and that's it. Reason being if you launched a "new product" at Google you got a huge bonus and a promotion, and a free image format no one wanted or asked for that went nowhere counts, while a free engineering standard like JPEG XL did not. So screw your "interoperability" I want my bad incentive money!
    • by thegarbz ( 1787294 ) on Sunday November 23, 2025 @07:45PM (#65814273)

      So let's follow this theory, to what end? WebP was developed by Google. What do they get from its adoption? It's an open format, a free format, and has a public specification. That gives Google very little in the way of any benefit from pushing it. It offers them no advantage over any other image format. Likewise if the point was to push something developed by Google it's worth noting that Google was one of the core contributors to JPEG-XL. It's only marginally less Google than WebP is.

      I suspect this was as simple and plain as expected. JPEG-XL didn't look like it was gaining any traction. It wasn't used, support was half-baked and experimental in Chrome, so they abandoned it. No surprise there, Google has killed things far more popular.

      On the flip side what happened recently forced an issue, PDF's adoption of JPEG-XL. Google maintains an inbuilt PDF reader in Chrome, meaning they now *need* to actually add JPEG-XL support if they want to remain PDF compliant. It's no longer an optional addition of something no one uses, but now becomes a PDF standards issue.

      • by AmiMoJo ( 196126 )

        It was mostly down to the available implementations of JPEG XL being crap. The reference C library had an unstable API, and performance was mediocre. They were still addressing some pretty severe security related bugs with every release. It was immature and not suitable for shipping with a web browser.

        Now there are better options, Google can integrate it safely.

  • Why not just top it off with Kaperski anti-virus. LOL!
  • uh (Score:4, Insightful)

    by drinkypoo ( 153816 ) <drink@hyperlogos.org> on Sunday November 23, 2025 @06:23PM (#65814179) Homepage Journal

    Windows 11 users can add native support through an image extension from Microsoft Store

    That's not what "native" means.

    Who invented pluggable file formats anyway? The first place I experienced it was AmigaOS 2.0. NeXTStep had reusable controls but AFAIK it didn't provide formats to all installed applications.

    • That's not what "native" means.

      It's exactly what it means, it becomes a core codec that all of Windows programs can universally use, managed by the OS, native support. Just because it's it's not there by default doesn't mean it isn't native to the OS.

      Or what do you claim it to be? Where do you draw the line? The kernel? Is nothing in the OS userland "native"?

      • That's not what "native" means.

        It's exactly what it means, it becomes a core codec that all of Windows programs can universally use, managed by the OS, native support. Just because it's it's not there by default doesn't mean it isn't native to the OS.

        Or what do you claim it to be? Where do you draw the line? The kernel? Is nothing in the OS userland "native"?

        You know that's not true. By your definition, Windows natively supports every network card that requires a driver to work, natively supports every printer or scanner that requires a download before it works, and natively supports all the GPUs that haven't been released yet.

        Native support for a thing means in-box support.

        • Windows natively supports every network card that requires a driver to work

          And if Microsoft made the driver for windows, then that would be true. We're not talking about a 3rd party support from someone else here, it is in-box just a component that isn't shipped by default, it is still a windows first party component made by Microsoft.

          To extend the thought let's look at some examples:
          - Does windows natively support Hyper-V, or WSL? I don't think anyone would claim it doesn't, but it's not installed by default. You need to select it as an optional feature later.
          - Is selecting it as

          • Native means comes with the system. If you have to download it separately, it isn't native. It used to mean built in and operating without translation layers, but modern software is generally built with layers on layers from the get-go so that's no longer a meaningful distinction.

            Windows' support for basic VGA mode does not constitute meaningful support for GPUs which have not been released because you can use almost none of the functionality. So sure, it "supports" them... but only well enough to download

        • by allo ( 1728082 )

          No. Native means, that it is included seamlessly.

          Windows has for example native TCP/IP support, while QUIC is only supported on the application level in Chrome. Maybe Microsoft someday adds a native QUIC driver to the Microsoft Appstore, then you can install native support as addon.

    • by _merlin ( 160982 )

      NeXTStep did allow you to write image filters to add support for image formats to all applications. Mac OS X inherited this feature, although I think it stopped working at some point. I released free Mac OS X image filters for HP 49G GROB and Sony PlayStation TIM formats back in the day.

      • That's interesting to know. I never spent a lot of time with NeXTStep, though I have played with it a little bit. I think I have a VM for an x86 version around here somewhere, but it was a little crashy in a way that the 68k machines weren't and I don't know which piece's fault that is. I spent more time with OS X, but not a whole lot, so I didn't get that far into it.

    • Agree here. The continued facilitation and propagation with applying a "microservice dogma" approach everywhere puts more and more process crossing and DLL crossing boundaries into the computer, each of those crossing is a possible security hole.

  • by bsdetector101 ( 6345122 ) on Monday November 24, 2025 @06:27AM (#65814831)
    And never will.... it has a long history to not trust it !
  • This is good news because WEBP has been deprecated in favor of JPEG XL.

  • What web browsers should really support is JPEG 2000. https://www.adobe.com/creativecloud/file-types/image/comparison/jpeg-vs-jpeg-2000.html [adobe.com]

"If you lived today as if it were your last, you'd buy up a box of rockets and fire them all off, wouldn't you?" -- Garrison Keillor

Working...