Skip to content

JXL to JPG Converter

Browser-side — no upload
Last verified May 2026 — runs in your browser

JXL to JPG Converter — Next-Gen JPEG XL to Universal JPEG

Convert JPEG XL (JXL) images to the universally compatible JPG format. 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). JXL combines VarDCT and Modular modes, lossless and lossy operation, progressive decoding, and lossless transcoding from existing JPEG files (a JPEG re-encoded to JXL is on average 20% smaller while preserving the option to reconstruct the original JPEG bit-exactly). Browser support 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, picture elements, and image-set() per the Safari 17 release notes from WWDC23. Chrome 110 (February 2023) removed earlier flagged support; Chrome 145 (February 2026) re-introduced JXL decoding behind chrome://flags/#enable-jxl-image-format using the Rust-based jxl-rs decoder, not enabled by default. Firefox supports JXL only in Nightly via image.jxl.enabled; stable Firefox does not link libjxl. canvas.toBlob('image/jxl') is not supported in any browser as of 2026. 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 re-encodes the pixels as JFIF-wrapped JPEG (Hamilton, C-Cube Microsystems, 1 September 1992; ITU-T T.81 baseline DCT, 18 September 1992) using WHATWG Canvas + HTMLCanvasElement.toBlob('image/jpeg', quality). Quality 1–100 maps to JPEG quantisation table scaling per ITU-T T.81 Annex K — 85 is the standard web sweet spot. Files never leave the device.

Related: JXL to PNG JXL to WebP AVIF to JPG HEIC to JPG PNG to JPG JPG to PNG

How to convert JXL to JPG

  1. 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.
  2. Pick a JPG quality level. 85 is the standard web sweet spot per ITU-T T.81 Annex K; 90+ approaches visually lossless; below 70 produces visible blocking and ringing.
  3. libjxl decodes the JXL bitstream to RGB(A) pixels at native dimensions (Safari 17+ uses its native decoder pass-through for the same step).
  4. For JXL with alpha, the tool composites against a configurable background colour (default white) and Canvas toBlob('image/jpeg', quality) re-encodes to JFIF JPEG.
  5. Download the JPG. The original JXL stays on disk untouched — files never leave the device.

Common use cases

  • Emailing a JXL photo to recipients whose mail client (Outlook, Gmail web, Thunderbird) cannot render JXL inline.
  • Uploading JXL camera or design exports to a CMS, e-commerce platform, or government portal that rejects the .jxl extension.
  • Importing a JXL into a legacy desktop editor (Photoshop without the JXL plugin, GIMP versions before 3.0, older Lightroom Classic) that does not decode JXL.
  • Producing JPG fallbacks for Chrome 110-144 (February 2023 - February 2026) where JXL was removed from the browser before being re-introduced behind a flag in Chrome 145.
  • Producing a JPG mirror of a JXL master for sharing publicly while keeping the higher-fidelity JXL original locally.

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 after the deprecation. Firefox supports JXL only in Nightly via image.jxl.enabled; stable Firefox does not link libjxl. canvas.toBlob('image/jxl') is not supported in any browser. This tool ships libjxl compiled to WebAssembly to fill the gap.

Will the JPG be larger than the source JXL?

Yes, typically 1.3-2× larger at JPG quality 85. JXL's VarDCT + Modular pipeline (ISO/IEC 18181-1:2022) compresses far more efficiently than JPEG's 1992 DCT + Huffman pipeline (ITU-T T.81). Cloudinary and Google reference benchmarks show JXL averaging 20-30% smaller than JPEG at equivalent SSIM. This conversion sacrifices that size advantage for universal compatibility — use it only when the destination cannot decode JXL.

My JXL came from a JPEG via lossless transcoding. Can I get the original JPEG back?

Not via this tool. JXL's lossless JPEG transcoding feature lets libjxl reconstruct the bit-exact original JPEG when the JXL was created with the proper transcoding flag. This tool, however, decodes the JXL to pixels and re-encodes a fresh JFIF JPEG via Canvas — the output is a re-quantised JPEG at your chosen quality, not the original. To get the original JPEG back, run the JXL through libjxl's djxl command-line tool with default settings (it auto-detects transcoded JPEGs and reconstructs them bit-exactly).

What about transparency and HDR?

JPEG has no alpha channel and no HDR support, so both are lost. JXL alpha (8-bit or 16-bit per Modular sub-bitstream) is composited against a configurable background colour (default white) via the WHATWG Canvas 2D Context before JPEG encoding. JXL HDR (PQ or HLG transfer with BT.2020 / Display P3 colour primaries) is tone-mapped to SDR sRGB (IEC 61966-2-1:1999) because the standard Canvas 2D path operates at 8-bit sRGB. JPEG itself only carries 8-bit Y′CbCr per ITU-T T.81 baseline, so HDR cannot be preserved in JPG by definition.

Is libjxl safe to ship in the browser?

libjxl (github.com/libjxl/libjxl) is the BSD 3-Clause reference implementation maintained by the JPEG XL community led by Alakuijala, Sneyers, Szabadka, and Versari (with CLAs assigned to Google). The WebAssembly build runs sandboxed inside the browser like every other WASM module — no system access, no upload, no persistence. Chrome 145's re-introduction (February 2026) intentionally uses the Rust-based jxl-rs decoder for memory safety; for browser-side polyfilling, libjxl WASM is the standard choice.

What you trade going JXL → JPG — and the libjxl WebAssembly requirement

The pipeline is decode-the-JXL-to-pixels then re-encode-as-JFIF-JPEG with several technical considerations the bare format-swapping tools miss: (1) JXL supports both lossy (VarDCT) and lossless (Modular) modes plus progressive decoding, but its full feature set — alpha channel, HDR via PQ/HLG transfer, Wide Color Gamut (BT.2020 / Display P3) — gets flattened by JPEG, which has no alpha and no HDR/WCG support. Transparent JXL pixels are composited against a configurable background colour (default white) via the WHATWG Canvas 2D Context before encoding, and HDR JXLs are tone-mapped to SDR sRGB (IEC 61966-2-1:1999) since the standard Canvas 2D path operates at 8-bit sRGB. (2) If the source JXL was itself a lossless transcoding of an existing JPEG (a common production workflow per Cloudinary's reference content), libjxl can reconstruct the original JPEG bit-exactly via the djxl command-line tool — but this tool decodes to pixels and re-encodes via Canvas, so the output is a fresh JPEG re-quantised at your chosen quality, not the original. (3) Quality control (1–100) maps to JPEG quantisation table scaling per ITU-T T.81 Annex K — 85 is the standard web sweet spot, 90+ approaches visually lossless, below 70 produces visible 8×8 blocking and ringing. (4) Output file size is typically 1.3–2× larger than the source JXL for photographs because JXL's VarDCT + Modular pipeline compresses far more efficiently than 1992-vintage JPEG DCT + Huffman. Use this conversion when compatibility outweighs size: emailing JXL to non-Safari recipients, uploading to a CMS that rejects .jxl, importing into a legacy editor, or producing fallbacks for Chrome 110-144 where JXL decode was unavailable between February 2023 and the Chrome 145 re-introduction.

  • 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
  • Adjustable JPEG quality 1–100 mapped to ITU-T T.81 Annex K quantisation tables
  • Configurable background colour for alpha compositing (transparent JXL → opaque JPEG)
  • Output JFIF v1.02 container (Hamilton, C-Cube Microsystems, 1 September 1992) widely accepted by legacy editors and CMS platforms
  • Browser-side via WHATWG Canvas + HTMLCanvasElement.toBlob('image/jpeg', quality) — no upload
  • Workaround for Chrome 110-144 (Feb 2023 - Feb 2026 gap) and stable Firefox where JXL decode is unavailable
  • Required when the destination cannot accept .jxl or image/jxl media types (most non-Safari ecosystems)

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 specification; defines VarDCT + Modular modes, lossless and lossy operation, progressive decoding, and lossless transcoding from existing JPEG files.
  • 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 format (.jxl extension, image/jxl media type); ISOBMFF-derived box structure.
  • Alakuijala, J., Sneyers, J., Szabadka, Z., Versari, L., et al. (2024). libjxl — JPEG XL reference implementation. github.com/libjxl/libjxl (BSD 3-Clause + Additional IP Rights Grant; Cloudinary + Google CLA contributions) — primary open-source JXL decoder; compiled to WebAssembly for browser-side JXL decoding when canvas.toBlob('image/jxl') is unsupported (no browser as of 2026).
  • ITU-T (CCITT) Study Group VIII & ISO/IEC JTC 1/SC 29/WG 10 (JPEG) (1992). Information technology — Digital compression and coding of continuous-tone still images: Requirements and guidelines. ITU-T Recommendation T.81 (18 September 1992) / ISO/IEC 10918-1:1994 — target JPEG baseline DCT bitstream; quality 1–100 maps to Annex K quantisation tables.
  • Hamilton, E. (C-Cube Microsystems) (1992). JPEG File Interchange Format (JFIF) Version 1.02. 1 September 1992 — target de facto JPEG container; APP0 marker, density units, thumbnail handling.
  • 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 to a canvas at native dimensions → toBlob('image/jpeg', quality) re-encodes via the browser's built-in JPEG encoder.
  • 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 JPEG 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.

Sponsored

By ·