Yes, JPEG XL keeps metadata. In our tests a lossless JPG-to-JXL conversion kept the camera details, author name, GPS location and XMP, and turned back into a byte-for-byte copy of the original JPEG. The catch is that JXL can compress that metadata, so a quick text search of the file finds nothing, and some EXIF viewers, including ours, can't read JXL yet.
Yes. A JPEG XL file can be a bare image stream with nothing else in it, or a container made of boxes, and the boxes can carry the same EXIF and XMP data a phone JPEG does:
| Box | What it holds | Where you'll see it |
|---|---|---|
| jxlc / jxlp | The image itself | Every JXL (a bare JXL is just this) |
| Exif | Camera, date, author, software, GPS | Converted phone photos, cameras, editors |
| xml | XMP: creator, copyright, keywords, edit history | Adobe apps, asset managers |
| jbrd | Data to rebuild the original JPEG byte for byte | Lossless JPEG conversions |
| brob | Any of the above, Brotli-compressed | Encoders that compress metadata |
The last row is the one to know about. JPEG XL can Brotli-compress its metadata, and when it does, the GPS coordinates and your name aren't stored as readable text anymore. Searching the file for a name, which finds it instantly in a JPEG, comes up empty, even though any JXL-aware reader will show it.
To test this, we made a 1600 × 1200 JPEG with a camera make and model, an author name, a capture date, GPS coordinates, an XMP block and an sRGB color profile. Then we converted it with Python's Pillow library and the pillow-jxl plugin (which wraps libjxl, the reference JPEG XL library) and opened the results in Chromium 145.
| Route | EXIF (camera, author, date) | GPS | XMP | Color profile |
|---|---|---|---|---|
| JPG to JXL, lossless transcode (the usual default) | Yes, compressed | Yes | Yes | Yes |
| JXL back to the original JPG | Yes | Yes | Yes | Yes |
| JPG to JXL, re-encoded pixels | Yes | Yes | No | Yes |
| JXL re-saved as JXL | Yes | Yes | No | Yes |
| JXL to JPG, PNG or WebP (Pillow default) | No | No | No | PNG only |
| Browser canvas to JPG or WebP | No | No | No | sRGB only |
The default way to turn a JPEG into a JXL is a lossless transcode, and it keeps everything. In our test the JXL came out 22% smaller, and decoding it gave back a JPEG that was identical to the original, down to the last byte, GPS included. That's the whole point of the feature: you can convert an archive of JPEGs and get the originals back later. It also means converting to JXL is not a way to clean a photo.
Re-encoding the pixels instead of transcoding made a smaller file but still carried the EXIF block and GPS across, because the plugin copies EXIF by default. Only the XMP was dropped. ImageMagick 6, which we used for our WebP and AVIF tests, couldn't open JPEG XL at all.
| File | Bytes | Size vs. original | Metadata inside |
|---|---|---|---|
| Original JPEG | 294,340 | 100% | Full EXIF, GPS, XMP, color profile |
| Lossless JPEG transcode to JXL | 228,751 | 77.7% | Everything, compressed |
| JXL from the pixels, quality 90 | 201,356 | 68.4% | EXIF and GPS, no XMP |
It depends on the tool, and the results were the reverse of the transcode. Pillow's default save dropped all EXIF, GPS and XMP when writing JPG, PNG and WebP from a JXL. Copying the EXIF across by hand worked when the JXL had been made from a JPEG, but from a pixel-encoded JXL it wrote the data into the JPG in a form most viewers can't parse, while the author name was still sitting in the file. If you're writing code, check the output, don't assume.
Safari has displayed JPEG XL since version 17, and the Chromium 145 build we tested decoded all of our test files. Firefox doesn't support it by default. When we drew a JXL onto a browser canvas and exported it as JPG or WebP, the result had no EXIF, no GPS and no XMP, just a standard sRGB color profile. Asking the canvas for a JXL silently returned a PNG, so browsers can show JPEG XL but can't make it.
This is where JXL is awkward right now. Our EXIF viewer uses a parsing library that doesn't understand JPEG XL, and in our test it reported "No EXIF metadata found" for a JXL with full GPS coordinates. Don't treat a clean result on a JXL as proof. Until more tools catch up, use ExifTool on a computer, which supports JPEG XL, or check the original JPEG before converting it.
To remove the metadata, convert the JXL to JPG or PNG with a tool that strips on export, then confirm the result in the EXIF viewer, which does read JPG and PNG. Our image metadata remover cleans JPG and PNG files in your browser. If you're starting from a JPEG, strip it before converting to JXL; that way there's nothing to carry over.
We ran the same tests on AVIF and WebP, and every format behaved differently. If you're converting photos to shrink them for the web, the image compressor outputs JPG, PNG and WebP with the metadata removed.
Yes. JPEG XL stores EXIF and XMP in separate boxes next to the image, sometimes Brotli-compressed. A lossless JPG-to-JXL conversion kept the camera details, author, date, GPS and XMP in our test.
Not with the default lossless transcode. It kept the GPS coordinates and turned back into a byte-for-byte copy of the original JPEG. Re-encoding the pixels also kept GPS, because the encoder copied EXIF by default.
JPEG XL can compress its metadata with Brotli. In our lossless conversion the EXIF and XMP were stored compressed, so a text search for the author name found nothing, even though a JXL-aware reader showed it.
Safari has supported JPEG XL since version 17, and Chromium 145 decoded our test files. Firefox doesn't by default. Browsers can't create JXL through the canvas: asking for one returned a PNG.
Convert it to JPG or PNG with a tool that strips on export, then check the result. Browser canvas conversion and Pillow's default save both removed EXIF, GPS and XMP in our test. Or strip the original JPEG before converting.