JXL to PNG Converter — JPEG XL to Lossless PNG
Convert JPEG XL (JXL) images to the universally supported PNG format with lossless quality and alpha preserved end-to-end. JPEG XL is a next-generation image coding system standardised as ISO/IEC 18181-1:2022 (Core coding system, March 2022) and ISO/IEC 18181-2:2021 (File format) — main authors Alakuijala, Sneyers, Szabadka, Versari (Cloudinary + Google CLA). PNG (W3C Recommendation 10 November 2003 / ISO/IEC 15948:2004) uses lossless DEFLATE compression (RFC 1951 Deutsch, May 1996, LZ77 + Huffman with 32 KB sliding window) that preserves every pixel exactly, making it the natural target when you need pixel-exact JXL output for editing or archival. Browser support for JXL is uneven: Safari 17+ (released 26 September 2023 with macOS Sonoma; the iOS 17 build shipped 18 September 2023) decodes JXL natively in image tags. Chrome 110 (February 2023) removed JXL entirely; Chrome 145 (February 2026) re-introduced JXL decoding behind chrome://flags/#enable-jxl-image-format using the Rust jxl-rs decoder, not enabled by default. Firefox supports JXL only in Nightly via image.jxl.enabled; stable Firefox does not link libjxl. This tool decodes JXL client-side via libjxl (github.com/libjxl/libjxl, BSD 3-Clause) compiled to WebAssembly when the browser cannot decode natively, then encodes the pixels as PNG via WHATWG Canvas + HTMLCanvasElement.toBlob('image/png'). The conversion is fully lossless from the decoded pixels — alpha is preserved end-to-end, no quality slider applies (PNG is lossless by definition). Files never leave the device.
How to convert JXL to PNG
- Drop a .jxl file onto the tool. The first conversion downloads the libjxl WASM module on first use when the browser cannot decode natively, then it stays cached for subsequent conversions.
- libjxl decodes the JXL bitstream to RGB(A) pixels at native dimensions (Safari 17+ uses its native decoder pass-through for the same step).
- The decoded pixels are drawn to a WHATWG Canvas with alpha preserved (the Modular alpha sub-bitstream is honoured).
- Canvas toBlob('image/png') serialises pixels as PNG via the browser's built-in DEFLATE encoder — fully lossless from the decoded pixels.
- Download the PNG. The original JXL stays on disk untouched — files never leave the device.
Common use cases
- Opening a JXL photo in a design tool that does not yet read the format (older Photoshop without the JXL plugin, GIMP before 3.0).
- Archiving a JXL source as PNG for long-term storage where decoder availability over decades is uncertain — PNG is universally readable since 1996.
- Handing JXL-encoded assets to a client or collaborator whose tools only accept PNG (the bulk of pre-2024 desktop software).
- Getting a lossless PNG master from a JXL before re-encoding to another lossy format (chained conversions amplify quality loss; a PNG intermediate avoids that).
- Producing PNG fallbacks for Chrome 110-144 and stable Firefox where JXL decode is unavailable.
Frequently asked questions
Why doesn't my browser open JXL directly?
Browser support is uneven. Safari 17+ (released 26 September 2023 with macOS Sonoma; the iOS 17 build shipped 18 September 2023) decodes JXL natively. Chrome 145+ (February 2026) decodes JXL behind chrome://flags/#enable-jxl-image-format using the Rust jxl-rs decoder, not enabled by default. Chrome 110 through 144 (Feb 2023 - Feb 2026) had no JXL support. Firefox supports JXL only in Nightly via image.jxl.enabled; stable Firefox does not link libjxl, so the flag is a no-op there. This tool ships libjxl compiled to WebAssembly to fill the gap.
Will the PNG be larger than the JXL?
Yes, typically 2-4× larger for photographs. JXL's VarDCT + Modular pipeline (ISO/IEC 18181-1:2022) compresses far more efficiently than PNG's 1996 DEFLATE algorithm. The PNG is not a replacement for the JXL in file size; it is a compatibility replacement that trades size for universal editor support and lossless pixel preservation.
Does the conversion lose detail?
No, the decode-to-PNG step is lossless. The JXL is decoded to RGB(A) pixels via libjxl (or Safari 17+'s native decoder), and PNG encodes those pixels exactly via DEFLATE per RFC 1951 — no further compression artefacts are added. If the JXL itself was lossy (VarDCT mode at quality below 99), those artefacts ride along into the PNG output, but the conversion step itself adds nothing.
How does transparency survive?
Cleanly. JXL alpha is carried as a Modular sub-bitstream (8-bit or 16-bit per pixel) per ISO/IEC 18181-1:2022; the Canvas 2D Context conversion path preserves alpha bytes exactly into PNG's RGBA mode (or tRNS chunk for per-entry alpha for indexed-colour PNG) per W3C 2nd Edition. Note: JXL's 16-bit alpha is downconverted to 8-bit in the PNG output since standard browser Canvas operates at 8-bit precision.
What about HDR JXL photos with wide colour gamut?
HDR JXLs (PQ or HLG transfer with BT.2020 / Display P3 colour primaries, 10-bit or 12-bit) are tone-mapped to SDR sRGB (IEC 61966-2-1:1999) before PNG encoding because the standard Canvas 2D path operates at 8-bit sRGB. Wide-gamut and high-dynamic-range information is lost in the PNG output. PNG can carry 16-bit colour depth via the deep-colour extensions, but the browser Canvas does not expose that path — for HDR-aware archival, keep the JXL original.
Why PNG is the natural lossless target for a JXL — and the libjxl WebAssembly requirement
The conversion is decode-the-JXL-to-pixels-via-libjxl then encode-PNG-via-DEFLATE — with alpha preserved exactly. Output is typically 2-4× larger than the source JXL for photographs since JXL's VarDCT + Modular pipeline (ISO/IEC 18181-1:2022) compresses far more efficiently than PNG's 1996 DEFLATE algorithm — but PNG buys universal editor and archival compatibility, plus a defensive future-proofing in case JXL adoption stalls. JXL's 8-bit and 16-bit alpha (carried as a Modular sub-bitstream) maps directly to PNG's tRNS chunk (per-entry 8-bit alpha for indexed-colour PNG, or single colour-key for grayscale/truecolour) or RGBA mode (8-bit per channel) per the W3C 2nd Edition spec — the Canvas 2D Context conversion path preserves alpha bytes exactly: decode JXL → ImageBitmap with alpha → drawImage → toBlob('image/png') retains every transparent pixel. Note: JXL's 16-bit alpha is downconverted to 8-bit in the PNG output since the standard browser Canvas operates at 8-bit precision (PNG also supports 16-bit RGBA via deep-colour extensions, but Canvas does not expose that path). JXL HDR via PQ/HLG transfer with BT.2020 or Display P3 colour primaries is tone-mapped to SDR sRGB (IEC 61966-2-1:1999) by the standard Canvas 2D path, losing wide-gamut and high-dynamic-range information in the PNG output. The PNG is essentially a 'compatibility wrapper' for whatever pixels the JXL decoded to — preserving the JXL's exact 8-bit visual output at the cost of file size growth and any HDR/WCG metadata. Use this conversion when the destination cannot handle JXL (Photoshop without the JXL plugin, older GIMP, Lightroom Classic versions before HEIF/JXL plugins), when archival format certainty matters, or when you need a pixel-exact PNG master for further editing.
- JXL source decoded per ISO/IEC 18181-1:2022 + ISO/IEC 18181-2:2021 (Alakuijala, Sneyers, Szabadka, Versari)
- Decoder: libjxl (BSD 3-Clause, Cloudinary + Google CLA) compiled to WebAssembly, plus Safari 17+ native decode passthrough
- Lossless PNG output via WHATWG Canvas + HTMLCanvasElement.toBlob('image/png')
- Alpha channel preserved end-to-end — JXL Modular alpha → PNG tRNS or RGBA mode (8-bit precision)
- PNG output uses DEFLATE compression per RFC 1951 Deutsch (May 1996, LZ77 + Huffman, 32 KB sliding window)
- PNG specification: W3C Recommendation 10 November 2003 / ISO/IEC 15948:2004 (universal raster format)
- Workaround for Chrome 110-144 (Feb 2023 - Feb 2026 gap) and stable Firefox where JXL decode is unavailable
- Browser-side conversion — files never leave the device
Free. No signup. No file uploads. Ads via AdSense (consent required).
Sources (7)
- ISO/IEC JTC 1/SC 29/WG 1 (JPEG) (2022). Information technology — JPEG XL image coding system — Part 1: Core coding system. ISO/IEC 18181-1:2022 (first edition, March 2022) — source JXL bitstream; lossy + lossless modes, alpha channel via Modular sub-bitstream, progressive decoding.
- ISO/IEC JTC 1/SC 29/WG 1 (JPEG) (2021). Information technology — JPEG XL image coding system — Part 2: File format. ISO/IEC 18181-2:2021 (first edition) / 2024 (second edition) — source JXL container; alpha channel preserved end-to-end into the PNG output.
- Alakuijala, J., Sneyers, J., Szabadka, Z., Versari, L., et al. (2024). libjxl — JPEG XL reference implementation. github.com/libjxl/libjxl (BSD 3-Clause; Cloudinary + Google CLA) — primary open-source JXL decoder compiled to WebAssembly for browser-side use.
- W3C (PNG Working Group) (2003). Portable Network Graphics (PNG) Specification (Second Edition). W3C Recommendation 10 November 2003 / ISO/IEC 15948:2004 — target lossless raster format with alpha channel preserved end-to-end from JXL source.
- Deutsch, P. (1996). DEFLATE Compressed Data Format Specification version 1.3. RFC 1951, IETF (May 1996, Aladdin Enterprises — LZ77 + Huffman; PNG IDAT compression algorithm).
- WHATWG (live). HTML Living Standard — Canvas 2D Context + HTMLCanvasElement.toBlob(). html.spec.whatwg.org/#2dcontext — browser conversion mechanism: decode JXL via libjxl WebAssembly (or Safari 17+ native) → drawImage with alpha → toBlob('image/png') retains every transparent pixel exactly.
- International Electrotechnical Commission (IEC) (1999). Multimedia systems and equipment — Colour measurement and management — Part 2-1: Default RGB colour space — sRGB. IEC 61966-2-1:1999 — default 8-bit RGB colour space targeted by the standard Canvas 2D path; HDR JXLs in BT.2020 / Display P3 are tone-mapped to SDR sRGB before PNG encoding.
These are the W3C, ISO/IEC, ITU-T, and IETF specifications the tool implements or builds on. Locate them on w3.org, iso.org, itu.int, or datatracker.ietf.org.
By Marco B. ·