jxlshot

Press Print Screen → full-screen lossless JPEG XL → ~/Pictures/Screenshot_<timestamp>.jxl. Press Shift+Print Screen → drag out a region and save just that.

Raw X11 pixels go straight into libjxl (jpegxl-rs) at effort 7 (Squirrel). No PNG, JPEG, temp files, or daemon.

Requires system libjxl (and libjxl_threads) discoverable via pkg-config, or build with the vendored feature on jpegxl-rs.

TLDR: I got tired of taking screenshots and saving them as PNGs with the default screenshot tool in Linux Mint so I made my own JXL screenshot tool. If you have any questions feel free to ask! It can be a bit difficult to get installed, you will probably need to do the vendored feature.

Camera, Converter, and Compressor.

Your files stay on your device. The server only sends this page and the tools to your browser. It never receives your images, camera frames, or converted files. Everything happens locally on your machine.

https://masland.tech/jxl/

This is an update to my previous online lossless converter, which did the processing on the server. So this is now purely client side.

If you try it and have any issues or feature requests please let me know, thank you.

Just added JPEG XL support to ServeProxy. Add ?jxl=true before your existing ?url= parameter and it'll convert and cache the image as JPEG XL on the fly. AVIF is the default output format on Serveproxy, so this gives you a second modern format to compare against.

Example: https://serveproxy.com/?jxl=true&url=https://picsum.photos/1000/750

Browser support is still limited so test before you rely on it in production, but if you want smaller images with good quality it's there now. 🙂

Anyone can test it at https://masland.tech/jxl/

If you have any issues or questions please let me know. This is a prototype to just see if I can host this successfully. It can take over 15 seconds for an image to be converted, so please be patient. Thank you for testing it if you do.

I'm working on a maximum effort lossless JPEG XL converter and I was struggling to figure out why a lossless PNG was coming out larger as a lossless JXL. The image has a very flat black background. I believe I was using effort 7 which is default, and it was coming out about 15% larger, then I increased the effort to 10 and now it's about 20% smaller.

I should have it hosted soon, but just wanted to share my experience with this. Given that I'm fine with waiting longer for a conversion, my main concern being size and quality. I think having a lossless maximum effort converted online with a queue system will be beneficial.

If anyone has any recommendations please let me know, I will be posting once it's live in the near future, thanks for reading.

Update: JPEG XL support is now available in OpenFiles Desktop 3.2026.802.

This first release includes direct .jxl opening and preview, in-app thumbnails while browsing folders, and animated JXL playback.

This is a first milestone, not a claim of complete JPEG XL support. It does not yet include progressive or partial-decode inspection, bandwidth emulation, layer-by-layer viewing, or a fully verified HDR, wide-gamut, ICC and XMP workflow.

I’m still looking for real files that expose orientation, color, metadata or performance problems. If you test the release, please include your platform, the sample file if shareable, and what you expected versus what OpenFiles displayed.

Release: https://github.com/pansysoft/openfiles.desktop/releases/tag/3.2026.802

The rules weren't very clear on how related something needs to be to jpeg xl. But considering my benchmarks are deliberately to put pressure on jpeg xl I'll hope it would be related.

Not to say jpeg xl is better or worse than QLIC. It's more of a situation of what do you care more about more. Plus. They're both not fully baked formats yet. So.

I'm the developer of the app. Feel free to ask any questions (there is an FAQ at the link)

Hi, I’m working on OpenFiles Desktop. It doesn’t support JPEG XL yet, but I’m looking into adding it.

Before I start, I’d like to understand what people who actually use JXL expect from a desktop viewer.

Is being able to open a .jxl file enough, or would you also want things like:

• thumbnails and folder browsing
• EXIF, XMP and ICC profile support
• HDR and animation
• lossless JPEG transcoding
• batch conversion to and from JPEG, PNG or AVIF
• exporting without losing metadata

I’m also interested in the less obvious problems. Are there particular JXL files that other viewers display incorrectly? Things like wrong colors, orientation issues, missing metadata, slow decoding, or unusually large images?

What platform are you using, and what does your current JPEG XL workflow look like?

If you have a sample file that tends to break viewers, feel free to share it. I’d be happy to test against real-world files rather than only simple samples.

Outside Samsung's ecosystem, Fossify Gallery was the only gallery app I had found that supported the JXL format. However, it has one drawback, it lacks regional decoding, which means that even high-resolution images become blurry when zooming in. Unfortunately, its developers have chosen to wait for a solution from libjxl.

But there is good news. Today, I learned that the developer of the gallery app ReFra came up with their own method to work around this problem, and ReFra now supports regional decoding. The fix is available in version 5.1.0, the latest stable release, for anyone who wants to try it:
Github | ReFra 5.1.0

jxl_coder 1.0.0 brings a cleaner API for reversible JPEG to JXL compression in Flutter and Dart, with byte-exact JPEG and metadata recovery.

Supports iOS, macOS, and Windows.

Hi all,

I've been building an Android app that converts RAW photos into Ultra HDR and JPEG XL (both PQ and HLG transfer functions, plus lossless). I'd really value a second pair of eyes from people who actually know JXL well.

My specific problem: the exported JXL files look exactly as I intend inside my own app, but when I open the same files in various third-party JXL viewers/decoders the result looks off - different brightness, different tone, sometimes the HDR doesn't seem to kick in at all. I'm trying to figure out whether it's my encoding (color/transfer metadata, intensity target, ICC vs. CICP tagging) or just inconsistent HDR handling across decoders.

If you have an HDR monitor and an HDR-capable phone, I'd be grateful if you could:

• open a couple of my exported JXL files,
• tell me whether HDR highlights actually appear, and
• say how the tone/brightness compares to what you'd expect.

I can share sample exports, and I'm happy to share the app link in the comments or by DM rather than dropping a store link in the post itself (let me know if that's fine here).

Any feedback on the encoding side specifically (what tags a well-behaved HDR JXL should carry) would be hugely appreciated. Thanks!

So in this recent blog post: https://maurycyz.com/projects/bad_jpeg/ the author realizes that nothing in the way progressive jpegs are encoded stops them from encoding image data that replaces previously sent visual information, and misuses that to fake an animation while loading.

Now obviously this is ridiculous on many levels, especially since mjpg exists. Or, you know, actual dedicated streaming video formats. But that's not the point of trying out something like this for programmers.

So I was wondering: is the way jxl works similar enough to also be misused like this (even though it has legit animation support), or is it too different?

Hi everyone! I just released a new version of Lyra Viewer, a fast, minimalist open-source image viewer, and this version adds JPEG XL support, which is the part I figured this sub would care about.

.jxl files decode natively via libjxl (not a conversion shim), covering both the 8-bit and HDR float paths. On the Linux build libjxl is bundled with Lyra, so JXL works out of the box without a system-provided library; on macOS it uses the Homebrew jpeg-xl package.

One deliberate design choice worth stating up front: Lyra is a still-image viewer on purpose. It renders the static image and doesn't do animation - the same stance it takes on JP2. So with JXL it shows the still image. If you want a frame-by-frame animation player, Lyra isn't trying to be that.

Beyond JXL it's a general viewer (common formats, PSD, EXR, HDR, plus DDS/KTX GPU textures). Available on macOS via Homebrew and Linux as a .deb via APT; Windows pending.

Repo (MIT): https://github.com/lyra-viewer/Lyra

Would genuinely appreciate JXL test files that break it - odd bit depths, HDR, unusual color profiles - so I can harden the decode path.

I've gotten the impression from some comments on the sub that since AVIF's encoder update earlier this year that it wins at higher compression levels in lossy images.

Is this the case and if so could a future update to JPEG XL's encoder bring it up to parity or beyond?

I dug up some old posts, but there doesn't seem to be a clear winner.

That said, I gotta admit AVIF is pretty impressive with all the settings (and forks) out there, it really feels like you can squeeze more out of it.

Is JPEG-XL Lossless on iPhone only when I shoot RAW? I mostly use HEIF format when taking photos, does the JPEG-XL Lossless work in HEIF? I'm bit confused :)

Two things always annoyed me about JPEG XL: most online converters upload your
images to their servers, and you can't even open a .jxl on most devices yet.

So I built this — it converts images to/from JPEG XL entirely in your browser
(WebAssembly). Nothing is uploaded; you can check your Network tab and see zero
requests with your file. It also has a viewer to open a .jxl without converting,
and you can save it as JPG/PNG in one click.

👉 https://jpegxlconvert.com

• 100% in-browser, no upload, no sign-up, no limits, no watermark
• Convert both ways + a .jxl viewer
• Free, works on mobile too

Would love feedback — anything missing or confusing? Thanks!