JPEG XL in GIMP
GIMP reads .jxl files since 2.10.32 and writes them since 2.10.34 — but only GIMP 3 gives you a real export dialog, with lossless, quality, effort and 16-bit. Here's what each setting does, measured, which builds include JPEG XL at all, and how to fix “Unknown file type”.
by Robert Castillo · Published
The short answer
Yes, GIMP handles JPEG XL, but how well depends entirely on the version. The plug-in was written by Daniel Novomeský for the GIMP 3 development series in 2021, and the 2.10 branch only received parts of it later. In October 2026 the current release is GIMP 3.2.6 (10 September 2026), and it has the complete version.
If you are still on 2.10, you can open .jxl files from 2.10.32 (June 2022) and export them from 2.10.34 (February 2023) — but that export has no settings at all: every file comes out 8-bit and lossless, which is large and drops the extra precision of 16-bit images. The full dialog, with lossy compression, effort and 16-bit, arrived with GIMP 3.0 on 16 March 2025, and GIMP 3.2 kept exactly the same options.
There's one more condition: GIMP only includes JPEG XL when it was built with the libjxl library. The official downloads for Windows and macOS are; distribution packages and older builds may not be. That's where the “Unknown file type” message comes from.
| Version | Open .jxl | Export .jxl |
|---|---|---|
| 2.10.30 and older | No | No |
| 2.10.32 (Jun 2022) | Yes | No |
| 2.10.34 – 2.10.38 | Yes, with metadata | 8-bit lossless only, no options |
| 3.0 (Mar 2025) – 3.2.6 (Sep 2026) | Yes | Full dialog: lossy, lossless, effort, 16-bit, CMYK |
How to export a JPEG XL in GIMP 3
Export, don't save
File › Save only writes GIMP's own .xcf. Use File › Export As… (Shift+Ctrl+E, or Shift+Cmd+E on a Mac).
Pick the format
Type a name ending in .jxl, or open Select File Type and choose JPEG XL image. If it isn't in the list, your build has no JPEG XL support — see the problems section.
Set the options
Click Export and the Export Image as JPEG XL dialog opens. Choose Lossless or a Compression/maxError value, an Effort/Speed preset and the bit depth; the next section explains each one.
Keep the .xcf
GIMP merges the visible layers into a single image when it exports. Your layered work survives only in the .xcf, so save that as well.
The export dialog, setting by setting
These are the exact options of GIMP 3.0 to 3.2.6, taken from the plug-in's source code, with their defaults. GIMP passes them almost directly to libjxl, the reference encoder.
| Option | Range and default | What it does |
|---|---|---|
| Lossless | Off by default | Stores every pixel exactly; greys out Compression/maxError |
| Compression/maxError | 0.1 to 15, default 1.0 | The butteraugli distance: lower means better quality and bigger files; GIMP's tooltip calls 1.0 “visually lossless” |
| Effort/Speed | lightning (1) to tortoise (9), default squirrel (7) | How hard the encoder works: time against accuracy and size |
| Bit depth | 8 bit/channel (default) or 16 bit/channel | Precision stored in the file |
| Export as CMYK | Only with a CMYK soft-proof profile | Writes a CMYK JPEG XL using that profile |
| Save Exif / Save XMP | Follow your preferences | Copies the photo's metadata into the file |
The effort presets have names instead of numbers: lightning (1, fastest), thunder (2), falcon (3), cheetah (4), hare (5), wombat (6), squirrel (7), kitten (8) and tortoise (9, slowest). They are libjxl's own effort levels, the same ones cjxl -e takes on the command line.
If you think in “quality” numbers from other programs, the conversion libjxl uses is distance = 0.1 + (100 − quality) × 0.09. So GIMP's default of 1.0 is quality 90, a distance of 0.5 is about 95 and 2.0 is about 79. And 1.0 is what GIMP's tooltip calls “visually lossless”; on SSIMULACRA2 it scored 84.8 and 77.2 in our test, under the 90 the metric calls visually lossless.
Measured: what the settings do to a real photo
GIMP hands these settings to libjxl, so we ran the same values through libjxl 0.12.0 on two public-domain photos of 14 and 45 megapixels. It's the same encoder library, not GIMP itself, so sizes can differ slightly with your GIMP build. Quality is scored with SSIMULACRA2: 80 means no difference visible side by side at 1:1, 90 means visually lossless.
| Compression/maxError | Photo A · 14 MP | Photo B · 45 MP |
|---|---|---|
| Original JPEG, for reference | 8.38 MB | 12.02 MB |
| 0.5 | 2.03 MB · 87.5 | 5.34 MB · 83.0 |
| 1.0 (default) | 0.99 MB · 84.8 | 2.91 MB · 77.2 |
| 2.0 | 0.50 MB · 78.6 | 1.32 MB · 69.5 |
| 3.0 | 0.33 MB · 73.1 | 0.81 MB · 61.9 |
| Lossless, 8-bit | 10.25 MB | 18.68 MB |
| PNG, for reference | 14.49 MB | 32.97 MB |
Each figure is the file size followed by the SSIMULACRA2 score. On photo A the default of 1.0 scored 84.8 at under a megabyte, where a JPEG at quality 90 of the same pixels needed 1.52 MB to reach 80.8, and 2.0 halved the file again while staying “high quality”. Photo B, a 45-megapixel portrait full of fabric texture, is harder: every step scores lower, 77.2 at 1.0 and 69.5 at 2.0, just under the “high quality” mark of 70. A value of 0.75 brought it to 79.8 at 3.79 MB, still smaller than its quality-90 JPEG (4.92 MB, 78.6). For detailed photos, lower the value a little rather than raising it.
Lossless is a different world: six to ten times the size of the default lossy file, but still 29–43% smaller than a PNG of the same pixels. That makes it the right choice for screenshots, graphics and masters, not for sending photos.
Effort/Speed: is tortoise worth it?
We encoded both photos at the default distance of 1.0 with presets from across the scale. Each cell gives the file size and the SSIMULACRA2 score; times are for photo A on a shared six-thread server under load, so read them as relative, not absolute.
| Effort/Speed | Photo A · 14 MP | Photo B · 45 MP | Time (A) |
|---|---|---|---|
| lightning (1) | 0.91 MB · 83.4 | 3.79 MB · 80.3 | 1.0 s |
| falcon (3) | 0.81 MB · 83.4 | 3.28 MB · 80.3 | 1.0 s |
| hare (5) | 0.96 MB · 84.7 | 2.86 MB · 77.1 | 3.0 s |
| squirrel (7), default | 0.99 MB · 84.8 | 2.91 MB · 77.2 | 6.2 s |
| tortoise (9) | 0.93 MB · 84.6 | out of memory (over 7.5 GB) | 92.2 s |
If you expected slower to mean smaller, the table says otherwise. At a fixed Compression/maxError, effort mostly changes how the encoder spends its bits, and the direction depends on the picture: on photo A the fast presets made smaller files that scored a little lower, on photo B they made files 12–30% bigger that scored higher. Hare and squirrel land in the same place on both. tortoise took fifteen times as long as squirrel on photo A for a file 6% smaller and no better.
It also costs memory. On photo A, tortoise peaked at about 4 GB of RAM against 0.4 GB for squirrel; on photo B it climbed past 7.5 GB and the system stopped it, on a 12 GB server shared with other jobs, while squirrel managed with 0.7 GB. On a machine short of memory, tortoise on a big photo can bring GIMP down. Leave it on squirrel.
Lossless is where effort pays. On photo A, lightning made a 13.77 MB file in half a second, squirrel 10.25 MB in about ten, and tortoise 9.98 MB in fifty. On photo B, squirrel came to 18.68 MB and tortoise to 18.48 MB after more than two minutes. For a handful of files, squirrel or kitten; tortoise only for archives you write once.
Bit depth 16 barely changed anything with our 8-bit sources: 1.3–1.6% bigger lossless, and the same size lossy. Pick 16 when the image really is 16-bit, from a raw developer or a scan, and leave 8 for everything else.
Windows, macOS, Linux and Flatpak
Whether your GIMP can do any of this depends on how it was built: GIMP's build system includes JPEG XL only if it finds libjxl, and silently leaves it out otherwise.
Windows
The installer from gimp.org is built with libjxl, so 3.x opens and exports .jxl out of the box. If an old 2.10 on Windows refuses, update rather than hunting for plug-ins.
macOS
The official .dmg bundles libjxl too. Recent versions of macOS already show .jxl in Finder and Preview (details here), so GIMP is only needed to edit or to choose export settings.
Linux distributions
Ubuntu 22.04 ships GIMP 2.10.30, with no JPEG XL at all. Ubuntu 24.04 (2.10.36) and Debian 12 (2.10.34) include the plug-in, limited to the 2.10 export. Debian 13 ships 3.0.4 and Ubuntu 26.04 3.2.2.
Flatpak
The Flathub build is GIMP 3.2.6. It takes libjxl from the GNOME runtime it runs on, which has included the library since the 24.08 base, so a current Flatpak exports JPEG XL with the full dialog.
On an old distribution, the Flatpak is the quickest way to a modern GIMP without touching system packages: flatpak install flathub org.gimp.GIMP. And if you only need to look at a file, our viewer opens it in any browser without installing anything.
Common problems and their fixes
| What happens | Why | Fix |
|---|---|---|
| “Opening '…jxl' failed: Unknown file type” | GIMP 2.10.30 or older, or a build without libjxl | Install 3.x from gimp.org or Flathub |
| JPEG XL isn't in Select File Type | Same cause; export also needs 2.10.34 or later | Same fix |
| Export has no options and the file is huge | GIMP 2.10 always exports 8-bit lossless | Use GIMP 3, or cjxl for lossy files |
| “Export as CMYK” is greyed out | No CMYK soft-proof profile is set | Image › Color Management › Soft-proof Profile… |
| A lossy .jxl opens as 32-bit floating point | Lossy files are decoded at full precision | Image › Encoding › 8-bit integer if memory matters |
| Your layers disappeared in the .jxl | Export merges visible layers | Keep the .xcf for editing |
One outdated tip still circulates: installing the JPEG XL plug-in that came with libjxl itself (packaged as libjxl-gimp-plugin). It was written for GIMP 2.10, in 2.10.32 it even took precedence over GIMP's own plug-in, and libjxl dropped it entirely in version 0.12.0 (July 2026). With GIMP 3 you don't need it; with 2.10, updating GIMP is the better fix.
The 32-bit surprise deserves a word. libjxl stores lossy files in its own perceptual colour space, and GIMP's loader decodes those at floating-point precision so nothing is rounded away. It's correct, but a 45-megapixel image in 32-bit takes a lot of memory. If you only need to crop and re-export, switching the encoding to 8-bit integer makes GIMP noticeably lighter. Files GIMP itself exported losslessly reopen at their own 8 or 16 bits.