Conversor de JXL a PNG — JPEG XL a PNG sin Pérdida
Convierte imágenes JPEG XL (JXL) al formato PNG universalmente soportado con calidad sin pérdida y alfa preservado extremo a extremo. 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). PNG (W3C Recommendation 10 de noviembre de 2003 / ISO/IEC 15948:2004) usa compresión DEFLATE sin pérdida (RFC 1951 Deutsch, mayo de 1996, LZ77 + Huffman con ventana deslizante de 32 KB) que preserva cada píxel exactamente, lo que lo hace el destino natural cuando necesitas salida píxel-exacta de un JXL para edición o archivo. El soporte de navegador para JXL 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. Chrome 110 (febrero de 2023) eliminó JXL del navegador; 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. 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 codifica los píxeles como PNG vía WHATWG Canvas + HTMLCanvasElement.toBlob('image/png'). La conversión es íntegramente sin pérdida desde los píxeles decodificados — el alfa se preserva extremo a extremo, no aplica control de calidad (PNG es sin pérdida por definición). Los archivos nunca salen del dispositivo.
Cómo convertir JXL a PNG
- 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.
- libjxl decodifica el bitstream JXL a píxeles RGB(A) en las dimensiones nativas (Safari 17+ usa su decodificador nativo en este paso).
- Los píxeles decodificados se dibujan a un Canvas de WHATWG con alfa preservado (el sub-bitstream alfa Modular se honra).
- Canvas toBlob('image/png') serializa los píxeles como PNG vía el codificador DEFLATE integrado del navegador — íntegramente sin pérdida desde los píxeles decodificados.
- Descarga el PNG. El JXL original queda intacto en el disco — los archivos nunca salen del dispositivo.
Casos de uso comunes
- Abrir una foto JXL en una herramienta de diseño que aún no lee el formato (Photoshop antiguo sin plugin JXL, GIMP anterior a 3.0).
- Archivar un origen JXL como PNG para almacenamiento a largo plazo con disponibilidad de decoder incierta a lo largo de décadas — PNG es universalmente legible desde 1996.
- Entregar assets JXL a un cliente o colaborador cuyas herramientas solo aceptan PNG (la mayor parte del software de escritorio anterior a 2024).
- Obtener un máster PNG sin pérdida desde un JXL antes de recodificar a otro formato con pérdida (las conversiones encadenadas amplifican la pérdida; un PNG intermedio lo evita).
- Producir alternativas PNG para Chrome 110-144 y Firefox estable donde la decodificación JXL no está disponible.
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. Firefox soporta JXL solo en Nightly vía image.jxl.enabled; el Firefox estable no enlaza libjxl, así que el flag no hace nada ahí. Esta herramienta envía libjxl compilado a WebAssembly para cubrir el hueco.
¿El PNG será mayor que el JXL?
Sí, normalmente 2-4× mayor para fotografías. La pipeline VarDCT + Modular de JXL (ISO/IEC 18181-1:2022) comprime mucho más eficientemente que el algoritmo DEFLATE de 1996 de PNG. El PNG no sustituye al JXL en tamaño; es un sustituto de compatibilidad que cambia tamaño por soporte universal de editores y preservación píxel-exacta sin pérdida.
¿La conversión pierde detalle?
No, el paso decodificar-a-PNG es sin pérdida. El JXL se decodifica a píxeles RGB(A) vía libjxl (o el decodificador nativo de Safari 17+), y PNG codifica esos píxeles exactamente vía DEFLATE según RFC 1951 — no se añaden artefactos de compresión adicionales. Si el JXL mismo era con pérdida (modo VarDCT a calidad por debajo de 99), esos artefactos siguen en la salida PNG, pero el paso de conversión en sí no añade ninguno.
¿Cómo sobrevive la transparencia?
Limpiamente. El alfa de JXL va como sub-bitstream Modular (8 o 16 bits por píxel) según ISO/IEC 18181-1:2022; la vía Canvas 2D Context preserva los bytes alfa exactamente al modo RGBA de PNG (o al chunk tRNS para alfa por entrada para PNG indexado) según la 2ª Edición de W3C. Nota: el alfa de 16 bits de JXL se reduce a 8 bits en la salida PNG porque el Canvas estándar del navegador opera a precisión de 8 bits.
¿Y las fotos JXL HDR con gama de color amplia?
Los JXL HDR (transferencia PQ o HLG con primarios de color BT.2020 / Display P3, 10 o 12 bits) se mapean tonalmente a SDR sRGB (IEC 61966-2-1:1999) antes de la codificación PNG 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 PNG. PNG puede transportar profundidad de color de 16 bits vía las extensiones de color profundo, pero el Canvas del navegador no expone esa vía — para archivo con HDR mantén el JXL original.
Por qué PNG es el destino sin pérdida natural de un JXL — y el requisito de libjxl WebAssembly
La vía es decodificar-JXL-a-píxeles-vía-libjxl y luego codificar-PNG-vía-DEFLATE — con alfa preservado exactamente. La salida es típicamente 2-4× mayor que el JXL origen para fotografías ya que la pipeline VarDCT + Modular de JXL (ISO/IEC 18181-1:2022) comprime mucho más eficientemente que el algoritmo DEFLATE de 1996 de PNG — pero PNG aporta compatibilidad universal con editores y archivo, además de un blindaje futuro por si la adopción de JXL se estanca. El alfa de 8 y 16 bits de JXL (transportado como sub-bitstream Modular) mapea directamente al chunk tRNS de PNG (alfa por entrada para PNG indexado) o al modo RGBA (8 bits por canal) según la 2ª Edición de W3C — la vía Canvas 2D Context preserva los bytes alfa exactamente: decodificar JXL → ImageBitmap con alfa → drawImage → toBlob('image/png') retiene cada píxel transparente. Nota: el alfa de 16 bits de JXL se reduce a 8 bits en la salida PNG porque el Canvas estándar del navegador opera a precisión de 8 bits (PNG también soporta RGBA de 16 bits vía las extensiones de color profundo, pero Canvas no expone esa vía). El HDR de JXL vía transferencia PQ/HLG con primarios de color BT.2020 o Display P3 se mapea tonalmente a SDR sRGB (IEC 61966-2-1:1999) por la vía Canvas 2D estándar, perdiendo gama amplia y alto rango dinámico en la salida PNG. El PNG es esencialmente un 'envoltorio de compatibilidad' para los píxeles que el JXL decodificó — preservando la salida visual exacta de 8 bits del JXL al coste de crecimiento de tamaño y cualquier metadato HDR/WCG. Usa esta conversión cuando el destino no puede manejar JXL (Photoshop sin el plugin JXL, GIMP antiguo, Lightroom Classic anterior a los plugins HEIF/JXL), cuando importa la certeza de formato para archivo, o cuando necesitas un máster PNG píxel-exacto para edición posterior.
- 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+
- Salida PNG sin pérdida vía WHATWG Canvas + HTMLCanvasElement.toBlob('image/png')
- Canal alfa preservado extremo a extremo — alfa Modular de JXL → tRNS o modo RGBA de PNG (precisión de 8 bits)
- La salida PNG usa compresión DEFLATE según RFC 1951 Deutsch (mayo de 1996, LZ77 + Huffman, ventana deslizante de 32 KB)
- Especificación PNG: W3C Recommendation 10 de noviembre de 2003 / ISO/IEC 15948:2004 (formato raster universal)
- 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 — los archivos nunca salen del dispositivo
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; 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.
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. ·