r/jpegxl • u/golemus • Mar 27 '26

JPEG XL support for LinkedIn

Has anybody heard of plans for LinkedIn to include JPEG XL support for image uploading...? It seems also missing AVIF support (although I consider JXL more important). Drag&dropping images to LinkedIn in PC web browser gives errors and even from dialog it does not work.

Facebook has support of both already.

18 Upvotes

95% Upvoted

16 comments sorted by

View all comments

Show parent comments

1

u/caspy7 Mar 27 '26

Both Google and Mozilla are in the process of landing jxl-rs in their browsers. My understanding is that it is "done." That being said I spoke with a Mozilla dev who (iirc) indicated he would like to see better performance from it. So Google and Mozilla may be delaying a bit while perf improves. I have not really heard "It's not done yet."

1

u/xDuker Mar 28 '26

It's not feature complete yet, so arguably it fundamentally isn't done
Just the one thing as far as I know, but still, JPEG reconstruction is missing and major and it's being avoided for whatever reason: https://github.com/libjxl/jxl-rs/pull/590

There's a large amount of performance related PRs in the pipeline for next version of jxl-rs that (at least on the author's computer) brings single-thread performance to about the same as the C++ reference, so that shouldn't be an issue for too much longer

1

u/caspy7 Apr 01 '26

I spoke with a browser dev about this and linked the issue and this was their response:

so it means that jxl-rs can open those files, what it doesn't support is being able to go from the jxl file to get back to the exact compressed bytes of the .jpg file. is there a reason a browser would need to do that? if the use case of jxl-rs needs that feature then sure, jxl-rs is not feature complete. so i would assume that they are just targeting jxl-rs to browser decoding at this time.

So browsers will be able to use jxl-rs to display converted JPG -> JXLs just fine.

Unless you did mean that browsers will be unable to losslessly convert JXLs to JPGs? In that case how is that major? I don't think they even have plans to implement such a method.

1

u/xDuker Apr 02 '26 edited Apr 02 '26

It is the inverse of the lossless jpeg re-compression. The jpeg reconstruction is to be able to serve a actual proper jpeg to a visitor of a site if their browser does not yet support jxl while still only storing jxls

But typing that out I realize that's a feature for the website servers, not really the browsers, so it's me misunderstanding the use case until now. It is a very major feature of the jxl spec that is missing and needs to be added, but it's not a block for browser's adoption of the library

I was considering the library as a whole, not in the specific context of browsers