JXL to WebP Converter — JPEG XL to Modern Universal WebP
Convert JPEG XL (JXL) images to the broadly supported WebP format with adjustable quality. JPEG XL (ISO/IEC 18181-1:2022 Core coding system, March 2022; ISO/IEC 18181-2:2021 File format) and WebP (RFC 9649 Zern, Massimino & Alakuijala, November 2024 — note Alakuijala is also a JXL author) are both modern image formats, but their browser-support trajectories diverged sharply. WebP is universally supported across Chrome, Firefox, Safari, and Edge (Safari decoding since version 14, 16 September 2020). JXL was added to Chrome 91 behind a flag (May 2021), removed entirely in Chrome 110 (February 2023), and re-introduced in Chrome 145 (February 2026) behind chrome://flags/#enable-jxl-image-format using the Rust jxl-rs decoder, not enabled by default. Safari 17+ (released 26 September 2023 with macOS Sonoma; the iOS 17 build shipped 18 September 2023) decodes JXL natively. Firefox supports JXL only in Nightly via image.jxl.enabled. canvas.toBlob('image/jxl') is not supported in any browser. WebP fills the universal-modern-format slot until JXL adoption catches up. 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 WebP per RFC 9649 via WHATWG Canvas + HTMLCanvasElement.toBlob('image/webp', quality). WebP encoding is native in Chrome 18+ / Edge 79+ (January 2020) / Firefox 96+ (January 2022); Safari does not support image/webp output via toBlob — Safari users in this tool path require a libwebp WebAssembly polyfill. Files never leave the device.
How to convert JXL to WebP
- 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.
- Pick a WebP quality level. 80-85 is a safe default for photographic content; lossless WebP is also available via quality=1.0 in Firefox 105+ (September 2022).
- libjxl decodes the JXL bitstream to RGB(A) pixels at native dimensions (Safari 17+ uses its native decoder pass-through for the same step).
- Canvas toBlob('image/webp', quality) re-encodes the decoded pixels as WebP per RFC 9649 — Safari users may need the libwebp WASM polyfill since Safari does not support image/webp output via toBlob.
- Download the WebP. The original JXL stays on disk untouched — files never leave the device.
Common use cases
- Shipping JXL assets to a CMS, browser, or platform that does not yet decode JXL but does decode WebP universally.
- Serving WebP variants in a picture element source list until JXL adoption catches up to WebP's universal support.
- Migrating a JXL-first asset pipeline back to WebP when stakeholder requirements demand broader browser coverage.
- Producing WebP copies for email templates and ad networks where JXL support is still uncommon.
- Producing WebP fallbacks for Chrome 110-144 (February 2023 - February 2026) and stable Firefox where JXL decode is unavailable.
Frequently asked questions
Why does my browser not decode JXL?
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. This tool ships libjxl compiled to WebAssembly to fill the gap.
Will WebP be smaller than the JXL?
Usually no. JXL's VarDCT + Modular pipeline (ISO/IEC 18181-1:2022) compresses around 20-25% more efficiently than WebP's VP8 + lossless modes (RFC 9649) at equivalent SSIM per Cloudinary and Google reference benchmarks. Expect WebP output 1.2-1.5× larger than the source JXL. Convert only when compatibility outweighs size — WebP is universally decoded across Chrome, Firefox, Safari, Edge, while JXL is decoded only by Safari 17+ natively and behind flags elsewhere.
Does transparency survive?
Yes. JXL's Modular alpha (8-bit or 16-bit) maps directly to WebP's alpha channel via the Canvas 2D Context conversion path; alpha bytes are preserved exactly (downconverted to 8-bit since the standard browser Canvas operates at 8-bit precision). Both JXL per ISO/IEC 18181-1:2022 and WebP per RFC 9649 §2.7.1.2 handle alpha as first-class.
What about HDR JXL?
HDR JXLs (PQ or HLG transfer with BT.2020 / Display P3 colour primaries) are tone-mapped to SDR sRGB (IEC 61966-2-1:1999) before WebP encoding because the standard Canvas 2D path operates at 8-bit sRGB. Wide-gamut and high-dynamic-range information is lost in the WebP output. Neither the WebP container per RFC 9649 nor the standard browser Canvas exposes HDR — for HDR-aware workflows keep the JXL original.
Why does Safari fail when I try to encode WebP?
WebP encoding (toBlob('image/webp', quality)) is supported natively in Chrome 18+ (2012), Edge 79+ Chromium, and Firefox 96+ (January 2022). Safari does NOT support WebP output via toBlob as of 2026 — Safari users hitting this tool path require a libwebp WebAssembly polyfill, which the tool ships when needed. WebP decoding (input) IS supported in Safari 14+ (16 September 2020) — the asymmetric gap is encoding only.
Modern-to-modern: why convert JXL to WebP — and the libjxl + libwebp WebAssembly path
The pipeline is decode-the-JXL-via-libjxl-WASM (or Safari 17+ native) then re-encode-as-WebP-via-Canvas. Both formats are modern, alpha-aware, and competitive on photographs, but the size trade-off favours JXL: typical JXL output is 20-25% smaller than WebP at equivalent SSIM per Cloudinary and Google reference benchmarks. So expect the WebP output to be 1.2-1.5× larger than the source JXL. The conversion is appropriate when (1) you need wider browser support than JXL currently offers — WebP is universally decoded since Safari 14 (16 September 2020) while JXL is currently decoded only by Safari 17+ natively, Chrome 145+ behind a flag, and Firefox Nightly behind a flag, and (2) you don't want to fall back to legacy JPEG. Both formats handle alpha cleanly: JXL's Modular alpha (8-bit or 16-bit) is composed onto a WebP alpha channel via the Canvas 2D Context (downconverted to 8-bit since browser Canvas operates at 8-bit precision); both formats also support animated content, though only animated JXL → animated WebP transcoding is well-defined per RFC 9649 §3 and ISO/IEC 18181-1:2022. JXL HDR via PQ/HLG transfer with BT.2020 / Display P3 colour primaries is tone-mapped to SDR sRGB (IEC 61966-2-1:1999) by the standard Canvas 2D path — neither the WebP container per RFC 9649 nor the standard Canvas path expose HDR. Use this conversion when JXL adoption blocks deployment but you want to keep modern compression rather than fall all the way back to JPEG.
- 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
- WebP target per RFC 9649 (Zern, Massimino, Alakuijala — Google LLC, November 2024 Informational)
- Adjustable WebP quality 1–100 mapped to VP8 quantiser (RFC 6386 Bankoski et al., November 2011)
- Alpha preserved end-to-end — JXL Modular alpha → WebP alpha via Canvas 2D (8-bit precision)
- WebP encoding native in Chrome 18+ / Edge 79+ (January 2020) / Firefox 96+ (January 2022); Safari requires libwebp WASM polyfill
- Workaround for Chrome 110-144 (Feb 2023 - Feb 2026 gap) and stable Firefox where JXL decode is unavailable
- Browser-side conversion via WHATWG Canvas + HTMLCanvasElement.toBlob('image/webp', quality) — no upload
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; VarDCT + Modular modes, lossy + lossless, alpha + animation.
- 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 (.jxl, image/jxl).
- 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.
- Zern, J., Massimino, P., & Alakuijala, J. (Google LLC) (2024). WebP Image Format. RFC 9649, IETF (November 2024, Informational) — target WebP container; lossy mode (VP8 keyframes) and lossless mode (LZ77 + Huffman/prefix coding) with alpha-preserving paths.
- Bankoski, J., Koleszar, J., Quillio, L., Salonen, J., Wilkins, P., & Xu, Y. (Google Inc.) (2011). VP8 Data Format and Decoding Guide. RFC 6386, IETF (November 2011, Informational) — VP8 keyframe bitstream used by WebP lossy mode.
- WHATWG (live). HTML Living Standard — Canvas 2D Context + HTMLCanvasElement.toBlob(). html.spec.whatwg.org/#2dcontext — browser conversion mechanism: decode JXL via libjxl WebAssembly → drawImage → toBlob('image/webp', quality); WebP encoding native in Chrome 18+ / Edge 79+ / Firefox 96+ since January 2022; Safari does NOT support image/webp output via toBlob — requires libwebp WebAssembly polyfill on Safari.
- 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 WebP 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. ·