this post was submitted on 13 Jan 2026
127 points (98.5% liked)

Technology

85606 readers
3663 users here now

This is a most excellent place for technology news and articles.


Our Rules


  1. Follow the lemmy.world rules.
  2. Only tech related news or articles.
  3. Be excellent to each other!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
  9. Check for duplicates before posting, duplicates may be removed
  10. Accounts 7 days and younger will have their posts automatically removed.

Approved Bots


founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] reddig33@lemmy.world 9 points 5 months ago* (last edited 5 months ago) (3 children)

What they’re saying is that a web server can create a traditional jpeg file from a jpeg xl to send to a client as needed. So you’re saving backend storage space… sometimes. Until widespread adoption by browsers, you’re still creating and transmitting a traditional jpeg file. And now you’ve increased the server space needed because you’re having to create and store two copies of the file in two different formats.

Developers are already doing this with webp and everyone hates webp (if your browser doesn’t support webp, the backend sends you the jpeg copy). I dont see any advantage here except some hand waving “but in the future” just like has been done for most new formats trying to win adoption.

[–] adespoton@lemmy.ca 3 points 5 months ago

And let’s not forget HEIF and JPEG-2000.

[–] logi@lemmy.world 3 points 5 months ago

The difference (claimed by the comment above) is in the words

without loss of quality

So you can convert back and forth without the photo copy of a photo copy problem.

And you don't have to store the second copy of the file except for caching of frequently fetched files which I'm sure will just be an nginx rule.

[–] The_Decryptor@aussie.zone 2 points 5 months ago

What they’re saying is that a web server can create a traditional jpeg file from a jpeg xl to send to a client as needed.

Other way around, you can convert a "web safe" JPEG file into a JXL one (and back again), but you can't turn any random JXL file into a JPEG file.

But yeah, something like Lemmy could recompress uploaded JPEG images as JXL on the server, serving them at JXL to updated clients, and converting back to JPEG as needed, saving server storage and bandwidth with no quality loss.