Conversor de JXL a JPG — JPEG XL de Nueva Generación a JPEG Universal
Convierte imágenes JPEG XL (JXL) al formato JPG universalmente compatible. JPEG XL es un sistema de codificación de imagen de nueva generación estandarizado como ISO/IEC 18181-1:2022 (sistema de codificación principal, marzo de 2022) e ISO/IEC 18181-2:2021 (formato de archivo) — autores principales Alakuijala, Sneyers, Szabadka, Versari (Cloudinary + Google CLA). JXL combina los modos VarDCT y Modular, operación con y sin pérdida, decodificación progresiva y transcodificación sin pérdida desde archivos JPEG existentes (un JPEG re-codificado a JXL es en promedio un 20% más pequeño y conserva la posibilidad de reconstruir el JPEG original bit a bit). 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 en etiquetas de imagen, elementos picture e image-set() según las release notes de Safari 17 de la WWDC23. Chrome 110 (febrero de 2023) eliminó el soporte previamente experimental; Chrome 145 (febrero de 2026) reintrodujo la decodificación JXL detrás de chrome://flags/#enable-jxl-image-format usando el decodificador en Rust jxl-rs, no activado por defecto. Firefox soporta JXL solo en Nightly vía image.jxl.enabled; el Firefox estable no enlaza libjxl. canvas.toBlob('image/jxl') no está soportado en ningún navegador a fecha de 2026. 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 JPEG envuelto en JFIF (Hamilton, C-Cube Microsystems, 1 de septiembre de 1992; ITU-T T.81 baseline DCT, 18 de septiembre de 1992) usando WHATWG Canvas + HTMLCanvasElement.toBlob('image/jpeg', quality). La calidad 1–100 mapea al escalado de tablas de cuantización JPEG según el Anexo K de ITU-T T.81 — 85 es el punto dulce web estándar. Los archivos nunca salen del dispositivo.
Cómo convertir JXL a JPG
- 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 JPG. 85 es el punto dulce web estándar según el Anexo K de ITU-T T.81; 90+ se aproxima a visualmente sin pérdida; por debajo de 70 produce bloques y ringing visibles.
- libjxl decodifica el bitstream JXL a píxeles RGB(A) en las dimensiones nativas (Safari 17+ usa su decodificador nativo en este paso).
- Para JXL con alfa, la herramienta compone contra un color de fondo configurable (blanco por defecto) y Canvas toBlob('image/jpeg', quality) re-codifica a JPEG JFIF.
- Descarga el JPG. El JXL original queda intacto en el disco — los archivos nunca salen del dispositivo.
Casos de uso comunes
- Enviar por correo una foto JXL a destinatarios cuyo cliente de correo (Outlook, Gmail web, Thunderbird) no renderiza JXL en línea.
- Subir exportaciones JXL de cámara o diseño a un CMS, plataforma de comercio electrónico o portal gubernamental que rechaza la extensión .jxl.
- Importar un JXL a un editor de escritorio heredado (Photoshop sin el plugin JXL, GIMP anterior a 3.0, Lightroom Classic antiguo) que no decodifica JXL.
- Producir alternativas JPG para Chrome 110-144 (febrero 2023 - febrero 2026) donde JXL fue retirado del navegador antes de reintroducirse detrás de un flag en Chrome 145.
- Producir un espejo JPG de un máster JXL para compartir públicamente mientras mantienes el JXL original de mayor fidelidad localmente.
Preguntas frecuentes
¿Por qué mi navegador no abre JXL directamente?
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 tras la deprecación. Firefox soporta JXL solo en Nightly vía image.jxl.enabled; el Firefox estable no enlaza libjxl. canvas.toBlob('image/jxl') no está soportado en ningún navegador. Esta herramienta envía libjxl compilado a WebAssembly para cubrir el hueco.
¿El JPG será más grande que el JXL origen?
Sí, normalmente 1,3-2× más grande a calidad JPG 85. La pipeline VarDCT + Modular de JXL (ISO/IEC 18181-1:2022) comprime mucho más eficientemente que la pipeline DCT + Huffman de JPEG de 1992 (ITU-T T.81). Los benchmarks de referencia de Cloudinary y Google muestran que JXL es de promedio 20-30% más pequeño que JPEG a SSIM equivalente. Esta conversión sacrifica esa ventaja de tamaño por compatibilidad universal — úsala solo cuando el destino no puede decodificar JXL.
Mi JXL vino de un JPEG vía transcodificación sin pérdida. ¿Puedo recuperar el JPEG original?
No con esta herramienta. La función de transcodificación JPEG sin pérdida de JXL permite a libjxl reconstruir el JPEG original bit a bit cuando el JXL fue creado con el flag de transcodificación apropiado. Esta herramienta, en cambio, decodifica el JXL a píxeles y re-codifica un JPEG JFIF fresco vía Canvas — la salida es un JPEG re-cuantizado a la calidad elegida, no el original. Para recuperar el JPEG original, pasa el JXL por la herramienta de línea de comandos djxl de libjxl con ajustes por defecto (auto-detecta JPEG transcodificados y los reconstruye bit a bit).
¿Y la transparencia y el HDR?
JPEG no tiene canal alfa ni soporte HDR, así que ambos se pierden. El alfa de JXL (8 o 16 bits según el sub-bitstream Modular) se compone contra un color de fondo configurable (blanco por defecto) vía el Canvas 2D Context de WHATWG antes de codificar JPEG. El HDR de JXL (transferencia PQ o HLG con primarios de color BT.2020 / Display P3) se mapea tonalmente a SDR sRGB (IEC 61966-2-1:1999) porque la vía Canvas 2D estándar opera a sRGB de 8 bits. JPEG mismo solo transporta Y′CbCr de 8 bits según ITU-T T.81 baseline, así que HDR no puede preservarse en JPG por definición.
¿Es seguro enviar libjxl al navegador?
libjxl (github.com/libjxl/libjxl) es la implementación de referencia BSD 3-Clause mantenida por la comunidad JPEG XL liderada por Alakuijala, Sneyers, Szabadka y Versari (con CLAs asignadas a Google). La build WebAssembly corre aislada dentro del navegador como cualquier otro módulo WASM — sin acceso al sistema, sin subida, sin persistencia. La reintroducción de Chrome 145 (febrero de 2026) usa intencionalmente el decodificador en Rust jxl-rs por seguridad de memoria; para polyfill del lado navegador, libjxl WASM es la opción estándar.
Qué cedes al pasar JXL → JPG — y el requisito de libjxl WebAssembly
La vía es decodificar-JXL-a-píxeles y luego re-codificar-como-JPEG-JFIF con varias consideraciones técnicas que las herramientas más básicas omiten: (1) JXL admite tanto el modo con pérdida (VarDCT) como sin pérdida (Modular) y decodificación progresiva, pero su conjunto de funciones — canal alfa, HDR vía transferencias PQ/HLG, Wide Color Gamut (BT.2020 / Display P3) — queda aplanado por JPEG, que no tiene alfa ni soporte HDR/WCG. Los píxeles JXL transparentes se componen contra un color de fondo configurable (blanco por defecto) vía el Canvas 2D Context de WHATWG antes de la codificación, y los JXL HDR se mapean tonalmente a SDR sRGB (IEC 61966-2-1:1999) porque la vía Canvas 2D estándar opera a sRGB de 8 bits. (2) Si el JXL origen fue a su vez una transcodificación sin pérdida de un JPEG existente (flujo común según el contenido de referencia de Cloudinary), libjxl puede reconstruir el JPEG origen bit a bit vía la herramienta de línea de comandos djxl — pero esta herramienta decodifica a píxeles y re-codifica vía Canvas, así que la salida es un JPEG fresco re-cuantizado a la calidad elegida, no el original. (3) El control de calidad (1–100) mapea al escalado de tablas de cuantización JPEG según el Anexo K de ITU-T T.81 — 85 es el punto dulce web estándar, 90+ se aproxima a visualmente sin pérdida, por debajo de 70 produce bloques 8×8 y ringing visibles. (4) El tamaño de archivo de salida es típicamente 1,3–2× mayor que el JXL origen para fotografías porque la pipeline VarDCT + Modular de JXL comprime mucho más eficientemente que el JPEG de 1992 con DCT + Huffman. Usa esta conversión cuando la compatibilidad pesa más que el tamaño: enviar JXL por correo a destinatarios sin Safari, subir a un CMS que rechaza .jxl, importar a un editor heredado o producir alternativas para Chrome 110-144 donde la decodificación JXL no estuvo disponible entre febrero de 2023 y la reintroducción en Chrome 145.
- 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+
- Calidad JPEG ajustable 1–100 mapeada a las tablas de cuantización del Anexo K de ITU-T T.81
- Color de fondo configurable para componer alfa (JXL transparente → JPEG opaco)
- Contenedor de salida JFIF v1.02 (Hamilton, C-Cube Microsystems, 1 de septiembre de 1992) ampliamente aceptado por editores heredados y plataformas CMS
- Lado navegador vía WHATWG Canvas + HTMLCanvasElement.toBlob('image/jpeg', quality) — sin subida
- Solución para Chrome 110-144 (hueco feb 2023 - feb 2026) y Firefox estable donde la decodificación JXL no está disponible
- Necesario cuando el destino no acepta .jxl ni el tipo MIME image/jxl (la mayoría del ecosistema fuera de Safari)
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 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.
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. ·