Conversor de JXL a WebP — JPEG XL a WebP Moderno Universal
Convierte imágenes JPEG XL (JXL) al formato WebP de soporte amplio con calidad ajustable. JPEG XL (ISO/IEC 18181-1:2022 sistema de codificación principal, marzo de 2022; ISO/IEC 18181-2:2021 formato de archivo) y WebP (RFC 9649 Zern, Massimino y Alakuijala, noviembre de 2024 — nota: Alakuijala es también autor de JXL) son ambos formatos de imagen modernos, pero sus trayectorias de soporte de navegador divergieron de forma marcada. WebP tiene soporte universal en Chrome, Firefox, Safari y Edge (Safari decodifica desde la versión 14, 16 de septiembre de 2020). JXL se añadió a Chrome 91 detrás de un flag (mayo de 2021), se eliminó en Chrome 110 (febrero de 2023) y se reintrodujo en Chrome 145 (febrero de 2026) detrás de chrome://flags/#enable-jxl-image-format usando el decodificador en Rust jxl-rs, no activado por defecto. Safari 17+ (lanzado el 26 de septiembre de 2023 con macOS Sonoma; la build de iOS 17 se distribuyó el 18 de septiembre de 2023) decodifica JXL de forma nativa. Firefox soporta JXL solo en Nightly vía image.jxl.enabled. canvas.toBlob('image/jxl') no está soportado en ningún navegador. WebP cubre el hueco de formato moderno universal hasta que la adopción de JXL se equipare. Esta herramienta decodifica JXL del lado cliente vía libjxl (github.com/libjxl/libjxl, BSD 3-Clause) compilado a WebAssembly cuando el navegador no puede decodificar de forma nativa, y luego re-codifica los píxeles como WebP según RFC 9649 vía WHATWG Canvas + HTMLCanvasElement.toBlob('image/webp', quality). La codificación WebP es nativa en Chrome 18+ / Edge 79+ (enero de 2020) / Firefox 96+ (enero de 2022); Safari no soporta la salida image/webp vía toBlob — los usuarios de Safari en esta vía requieren un polyfill libwebp en WebAssembly. Los archivos nunca salen del dispositivo.
Cómo convertir JXL a WebP
- Arrastra un .jxl a la herramienta. La primera conversión descarga el módulo WASM de libjxl la primera vez cuando el navegador no puede decodificar de forma nativa, después queda en caché para las conversiones siguientes.
- Elige el nivel de calidad WebP. 80-85 es un valor por defecto seguro para contenido fotográfico; el WebP sin pérdida también está disponible vía quality=1.0 en Firefox 105+ (septiembre de 2022).
- libjxl decodifica el bitstream JXL a píxeles RGB(A) en las dimensiones nativas (Safari 17+ usa su decodificador nativo en este paso).
- Canvas toBlob('image/webp', quality) re-codifica los píxeles decodificados como WebP según RFC 9649 — los usuarios de Safari pueden necesitar el polyfill libwebp WASM porque Safari no soporta la salida image/webp vía toBlob.
- Descarga el WebP. El JXL original queda intacto en el disco — los archivos nunca salen del dispositivo.
Casos de uso comunes
- Enviar assets JXL a un CMS, navegador o plataforma que aún no decodifica JXL pero sí decodifica WebP universalmente.
- Servir variantes WebP en una lista source de un elemento picture hasta que la adopción de JXL alcance el soporte universal de WebP.
- Migrar una pipeline de assets que prioriza JXL de vuelta a WebP cuando los requisitos de las partes interesadas exigen mayor cobertura de navegador.
- Producir copias WebP para plantillas de correo y redes de anuncios donde el soporte JXL sigue siendo poco común.
- Producir alternativas WebP para Chrome 110-144 (febrero 2023 - febrero 2026) y Firefox estable donde la decodificación JXL no está disponible.
Preguntas frecuentes
¿Por qué mi navegador no decodifica JXL?
El soporte de navegador es desigual. Safari 17+ (lanzado el 26 de septiembre de 2023 con macOS Sonoma; la build de iOS 17 se distribuyó el 18 de septiembre de 2023) decodifica JXL de forma nativa. Chrome 145+ (febrero de 2026) decodifica JXL detrás de chrome://flags/#enable-jxl-image-format usando el decodificador en Rust jxl-rs, no activado por defecto. Chrome 110 a 144 (febrero 2023 - febrero 2026) no tuvieron soporte JXL. Firefox soporta JXL solo en Nightly vía image.jxl.enabled; el Firefox estable no enlaza libjxl. Esta herramienta envía libjxl compilado a WebAssembly para cubrir el hueco.
¿WebP será más pequeño que el JXL?
Normalmente no. La pipeline VarDCT + Modular de JXL (ISO/IEC 18181-1:2022) comprime alrededor de 20-25% más eficientemente que los modos VP8 + lossless de WebP (RFC 9649) a SSIM equivalente según los benchmarks de referencia de Cloudinary y Google. Espera salida WebP 1,2-1,5× mayor que el JXL origen. Convierte solo cuando la compatibilidad pesa más que el tamaño — WebP se decodifica universalmente en Chrome, Firefox, Safari, Edge, mientras que JXL se decodifica solo por Safari 17+ de forma nativa y detrás de flags en otros navegadores.
¿Sobrevive la transparencia?
Sí. El alfa Modular de JXL (8 o 16 bits) mapea directamente al canal alfa de WebP vía la vía Canvas 2D Context; los bytes alfa se preservan exactamente (reducidos a 8 bits porque el Canvas estándar del navegador opera a precisión de 8 bits). Tanto JXL según ISO/IEC 18181-1:2022 como WebP según RFC 9649 §2.7.1.2 manejan alfa como ciudadano de primera clase.
¿Y el JXL HDR?
Los JXL HDR (transferencia PQ o HLG con primarios de color BT.2020 / Display P3) se mapean tonalmente a SDR sRGB (IEC 61966-2-1:1999) antes de la codificación WebP porque la vía Canvas 2D estándar opera a sRGB de 8 bits. La información de gama amplia y alto rango dinámico se pierde en la salida WebP. Ni el contenedor WebP según RFC 9649 ni el Canvas estándar del navegador exponen HDR — para flujos de trabajo con HDR mantén el JXL original.
¿Por qué Safari falla cuando intento codificar WebP?
La codificación WebP (toBlob('image/webp', quality)) está soportada de forma nativa en Chrome 18+ (2012), Edge 79+ Chromium y Firefox 96+ (enero de 2022). Safari NO soporta salida WebP vía toBlob a fecha de 2026 — los usuarios de Safari que llegan a esta vía requieren un polyfill libwebp en WebAssembly, que la herramienta envía cuando es necesario. La decodificación WebP (entrada) SÍ está soportada en Safari 14+ (16 de septiembre de 2020) — el hueco asimétrico es solo en codificación.
Moderno-a-moderno: por qué convertir JXL a WebP — y la vía libjxl + libwebp WebAssembly
La vía es decodificar-JXL-vía-libjxl-WASM (o nativo Safari 17+) y luego re-codificar-como-WebP-vía-Canvas. Ambos formatos son modernos, conscientes de alfa y competitivos en fotografías, pero el balance de tamaño favorece a JXL: la salida típica de JXL es 20-25% más pequeña que WebP a SSIM equivalente según los benchmarks de referencia de Cloudinary y Google. Así que espera que la salida WebP sea 1,2-1,5× mayor que el JXL origen. La conversión es apropiada cuando (1) necesitas más cobertura de navegador que la que JXL ofrece actualmente — WebP se decodifica universalmente desde Safari 14 (16 de septiembre de 2020) mientras que JXL se decodifica solo por Safari 17+ de forma nativa, Chrome 145+ detrás de un flag y Firefox Nightly detrás de un flag, y (2) no quieres recurrir a JPEG heredado. Ambos formatos manejan alfa con limpieza: el alfa Modular de JXL (8 o 16 bits) se compone sobre el canal alfa de WebP vía el Canvas 2D Context (reducido a 8 bits porque el Canvas del navegador opera a precisión de 8 bits); ambos formatos también soportan contenido animado, aunque solo la transcodificación JXL animado → WebP animado está bien definida según RFC 9649 §3 y ISO/IEC 18181-1:2022. El HDR de JXL vía transferencia PQ/HLG con primarios de color BT.2020 / Display P3 se mapea tonalmente a SDR sRGB (IEC 61966-2-1:1999) por la vía Canvas 2D estándar — ni el contenedor WebP según RFC 9649 ni la vía Canvas estándar exponen HDR. Usa esta conversión cuando la adopción de JXL bloquea el despliegue pero quieres conservar compresión moderna sin recurrir a JPEG.
- Origen JXL decodificado según ISO/IEC 18181-1:2022 + ISO/IEC 18181-2:2021 (Alakuijala, Sneyers, Szabadka, Versari)
- Decodificador: libjxl (BSD 3-Clause, Cloudinary + Google CLA) compilado a WebAssembly, además de paso nativo en Safari 17+
- Destino WebP según RFC 9649 (Zern, Massimino, Alakuijala — Google LLC, noviembre de 2024 Informational)
- Calidad WebP ajustable 1–100 mapeada al cuantizador VP8 (RFC 6386 Bankoski et al., noviembre de 2011)
- Alfa preservado extremo a extremo — alfa Modular de JXL → alfa WebP vía Canvas 2D (precisión de 8 bits)
- Codificación WebP nativa en Chrome 18+ / Edge 79+ (enero de 2020) / Firefox 96+ (enero de 2022); Safari requiere polyfill libwebp WASM
- Solución para Chrome 110-144 (hueco feb 2023 - feb 2026) y Firefox estable donde la decodificación JXL no está disponible
- Conversión del lado navegador vía WHATWG Canvas + HTMLCanvasElement.toBlob('image/webp', quality) — sin subida
Gratis. Sin registro. Sin subidas. Anuncios mediante AdSense (con consentimiento).
Fuentes (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.
Son las especificaciones del W3C, ISO/IEC, ITU-T e IETF que la herramienta implementa o sobre las que se apoya. Localízalas en w3.org, iso.org, itu.int o datatracker.ietf.org.
Por Marco B. ·