La compatibilidad de JPEG XL en los navegadores progresa notablemente en octubre de 2026: Chrome 155 y Firefox 158 descodifican desde el primer momento los archivos .jxl de forma predeterminada. Safari 17 los admite parcialmente, mientras que Edge 155 debe probarse directamente. Para un sitio profesional, JPEG XL resulta utilizable, pero únicamente junto con AVIF, WebP o JPEG como solución alternativa.
¿Qué navegadores son compatibles con JPEG XL en 2026?
La compatibilidad de JPEG XL en los navegadores incluye Chrome 155 desde el 6 de octubre de 2026 y Firefox 158 desde el 13 de octubre de 2026. Safari 17 ofrece una compatibilidad parcial sin renderizado progresivo. Los datos públicos sobre Edge 155 son contradictorios, por lo que es necesario probarlo en este navegador antes de cualquier implementación.
JPEG XL es un formato de imagen normalizado con la referencia ISO/IEC 18181 en 2021. Admite compresión con o sin pérdida, transparencia, animación, HDR (alto rango dinámico), espacios de color amplios y descodificación progresiva, que permite mostrar gradualmente una imagen mientras se carga.
Google activó la descodificación de los archivos .jxl, servidos con el tipo MIME (identificador del formato transmitido por el servidor) image/jxl, en Chrome 155 el 6 de octubre de 2026. Mozilla hizo lo mismo en la versión estable de Firefox 158 el 13 de octubre de 2026, después de haber pospuesto la activación inicialmente prevista en Firefox 157. KultureGeek confirmó esta disponibilidad en la versión final el 15 de octubre de 2026.
| Navegador | Versión | Estado | Decisión recomendada |
|---|---|---|---|
| Google Chrome | 155 | Compatible de forma predeterminada | Activar con alternativa |
| Mozilla Firefox | 158 | Compatible de forma predeterminada | Activar con alternativa |
| Manzana Safari | 17 y versiones posteriores | Compatibilidad parcial, sin renderizado progresivo | Probar y conservar una alternativa |
| Microsoft Edge | 155 | Datos contradictorios entre MDN y Can I Use | Probar directamente antes de la implementación |
| Navegadores antiguos | Variables | Compatibilidad inexistente o incierta | Servir AVIF, WebP o JPEG |
Can I Use estimaba la cobertura mundial en un 60,19 % a 21 de octubre de 2026, a partir de los usos de septiembre de 2026. Esta estimación muestra una tendencia, no una garantía para su audiencia. Un sitio B2B utilizado en empresas con navegadores administrados puede mantener versiones antiguas durante mucho más tiempo.
¿Hacen Chrome 155 y Firefox 158 que JPEG XL esté listo para producción?
Chrome 155 y Firefox 158 hacen que JPEG XL sea utilizable en producción en 2026, pero no como formato único. Una implementación fiable conserva una imagen alternativa para Safari, Edge y las versiones antiguas. La compatibilidad técnica también debe verificarse en el sistema de gestión de contenidos, el servidor y la red de distribución.
Firefox 158 también añade image/jxl a las cabeceras Accept de las solicitudes de imágenes. Esta cabecera indica al servidor qué formatos entiende el navegador. De este modo, un servidor o una CDN (red de distribución de contenidos) puede elegir automáticamente el archivo adecuado, siempre que su configuración utilice correctamente esta información.
La trampa poco visible suele encontrarse detrás del navegador. Una biblioteca multimedia puede rechazar el archivo, un módulo de optimización puede ignorarlo y una CDN puede asignarle un tipo MIME incorrecto. En los proyectos que llevamos a cabo, por tanto, verificamos toda la cadena, desde la exportación hasta la visualización, en lugar de conformarnos con una prueba correcta en Chrome.
Para entender por qué este regreso cambia la estrategia de imágenes, nuestra anterior guía sobre la llegada de JPEG XL a Chrome presenta también la historia del formato y su posición frente a WebP y AVIF.
¿Es JPEG XL más eficiente que AVIF y WebP?
JPEG XL no es sistemáticamente más ligero que AVIF o WebP. En 2026, Mozilla midió que AVIF era más compacto con una calidad comparable y con pérdida, pero que JPEG XL era más ligero en dos pruebas sin pérdida. Por ello, Google y Mozilla recomiendan comparar los formatos con imágenes representativas del sitio.
En las muestras publicadas por Mozilla el 24 de agosto de 2026, una fotografía sin pérdida ocupaba 1,45 MB en JPEG XL, frente a 1,76 MB en AVIF y 1,55 MB en WebP. Una captura de pantalla ocupaba 92 kB en JPEG XL, 164 kB en AVIF y 96 kB en WebP. Estos dos archivos ilustran una posible ventaja, no una regla universal.
Google indica en 2026 que JPEG XL puede ofrecer una compresión entre un 30 y un 50 % superior a la del JPEG histórico. Esta comparación no demuestra una mejora equivalente frente a AVIF. Una imagen AVIF bien codificada puede seguir siendo más pequeña cuando se acepta una ligera pérdida, especialmente en fotografías editoriales.
Sinceramente, convertir toda una fototeca porque un formato gana en dos ejemplos sería una mala decisión. Compare el peso, la calidad visual, el tiempo de codificación y el comportamiento en los dispositivos de sus visitantes. Para capturas de interfaz, archivos sin pérdida o imágenes HDR, merece especialmente la pena probar JPEG XL.
¿Cómo implementar JPEG XL sin romper las imágenes del sitio?
La implementación segura de JPEG XL se basa en el elemento HTML <picture>, que propone varios formatos dentro de un marco definido. El navegador elige la primera fuente que sabe descodificar y utiliza después la imagen JPEG final si ninguna fuente moderna es compatible. Este método protege a los visitantes que utilizan navegadores antiguos.
Una estrategia alternativa puede ofrecer primero JPEG XL, después AVIF, luego WebP y, por último, JPEG. Según la documentación de MDN consultada en 2026, los navegadores ignoran las fuentes cuyo tipo declarado no es compatible.
<picture><source srcset="photo.jxl" type="image/jxl"><source srcset="photo.avif" type="image/avif"><source srcset="photo.webp" type="image/webp"><img src="photo.jpg" alt="Descripción de la foto"></picture>
Una implementación prudente sigue estas comprobaciones:
- codificar una muestra de fotografías, ilustraciones y capturas de pantalla en lugar de toda la biblioteca multimedia;
- verificar el tipo MIME
image/jxlenviado por el alojamiento o la CDN; - probar Chrome 155, Firefox 158, Safari 17 y Edge 155 en ordenador y móvil;
- medir el peso transferido y la calidad visual frente a las versiones AVIF y WebP;
- conservar los originales y automatizar la alternativa antes de una puesta en producción general.
Por parte de la agencia, lo habitual es empezar con JPEG XL en una familia de imágenes medible, por ejemplo, los recursos visuales de un catálogo. Una validación técnica suele tardar entre 1 y 3 días laborables en 2026, sin contar el desarrollo de una canalización de codificación. Según los proveedores franceses, calcule entre 600 y 2.400 € sin IVA como mínimo si el CMS y la CDN requieren una integración específica.
¿Acepta WordPress imágenes JPEG XL?
WordPress no admite de forma nativa las cargas de imágenes JPEG XL a 21 de octubre de 2026. La lista de extensiones reconocidas por el núcleo de WordPress incluye JPEG, PNG, WebP y AVIF, pero no JXL. Hay un ticket abierto que propone esta evolución, sin demostrar que ya esté disponible en una versión publicada.
Añadir simplemente jxl a la lista de extensiones autorizadas no lo soluciona todo. WordPress también debe comprobar el contenido real del archivo, crear los tamaños intermedios y colaborar con la biblioteca de imágenes del servidor. De lo contrario, la administración puede aceptar el original sin poder producir las miniaturas requeridas por el tema.
El ticket WordPress Core 52788 menciona en 2026 la adición del tipo image/jxl, la verificación de los bytes característicos del format y la conservación del original lors de una conversión del lado del cliente. Son propuestas pendientes. No deben presentarse como funciones implementadas.
Para un sitio WordPress en producción, lo razonable es generar los archivos JXL horts de la biblioteca multimedia o mediante un proceso controlado y, a continuación, producir las etiquetas <picture>. En este punto, es preferible una integración limitada y reversible a una extensión improvisada que eluda los controles de seguridad.
¿Hay que adoptar JPEG XL ahora o esperar?
La adopción de JPEG XL es pertinente en 2026 lor cuando las ventajas se hayan medido con sus imágenes y exista un mecanismo de repliegue automático. Es mejor esperar si WordPress debe gestionar los archivos por sí solo, si Edge representa una parte significativa de la audiencia o si AVIF ya cumple los objetivos de peso sin añadir complejidad.
Por tanto, la compatibilidad de JPEG XL con los navegadores no basta para decidir. Consulte los datos de su herramienta de medición de audiencia, sin recopilar más datos personales de los necesarios, e identifique después las versiones que se utilizan realmente. Pruebe también las pantallas de alorta luminosidad si el interés del proyecto está relacionado con el HDR.
El beneficio debe superar el coste de explotación. Añadir un cuarto format aumenta el almacenamiento, los procesos de codificación, los controles de calidad y las posibilidades de error en las cachés. Para un sitio corporativo pequeño que ya es rápido con AVIF y WebP, el ahorro de unos pocos kilobytes no siempre justifica este trabajo.
Por el contrario, un medio de comunicación, un catálogo amplio o un servicio que gestione originales sin pérdida puede obtener una ventaja tangible. La estrategia razonable consiste en conservar las fuentes originales y tratar JPEG XL como una variante de distribución. Así, el format puede sustituirse sin rehacer toda la producción gráfica.
Definir los navegadores objetivo, los formats de respaldo y el proceso de codificación evita la mayoría de las imágenes ausentes y de los costes ocultos. Una perspectiva externa puede ayudar sobre todo a determinar si la mejora medida merece una nueva capa técnica.
Preguntas frecuentes sobre JPEG XL
¿Cuál es el tipo MIME de un archivo JPEG XL?
El tipo MIME de JPEG XL es image/jxl y su extensión es .jxl. El servidor debe enviar este tipo correctamente para evitar problemas de interpretación o de caché.
¿Se pueden sustituir todas las imágenes JPEG por archivos JXL?
Sustituir todos los JPEG por archivos JXL sin mecanismo de repliegue excluiría inclorso algunos navegadores en 2026. Una etiqueta <picture> con una fuente JPEG final mantiene el acceso a las imágenes.
¿JPEG XL mejora automáticamente el posicionamiento orgánico?
JPEG XL n’apporte pas de bonus SEO direct connu en 2026. Des images plus légères peuvent améliorer la vitesse perçue et certains indicateurs Core Web Vitals, mais seulement si l’intégration ne retarde pas l’affichage de l’image principale.
¿Cloudflare u OVHcloud convierten automáticamente las imágenes a JPEG XL?
La compatibilidad de un servicio de imágenes de Cloudflare o de una oferta de OVHcloud depende del producto y de su configuración en 2026. Compruebe explícitamente la generación JXL, el tipo MIME, la negociación de contenido y el comportamiento de la caché antes de confiar en una conversión automática.