Cómo elegir formatos de imagen para la web en 2026: el imperio de JPEG, el ascenso de AVIF y el exilio de JPEG XL

Toma una foto de 12 MP (4000 × 3000 píxeles) y expórtala de seis maneras. PNG: 24 MB. JPEG con calidad 90: 3,4 MB. WebP con una calidad visual equivalente: unos 2,4 MB. AVIF con una calidad visual equivalente: unos 1,7 MB. GIF, reducido con dithering hasta su techo de 256 colores: 6 MB, con banding visible por todas partes. SVG no está en la lista: describe dibujos, y una fotografía no lo es.

La misma imagen en pantalla, una diferencia de 14× en disco. Esa diferencia es ingeniería, no una cuestión de gustos. Cada formato es un conjunto de decisiones tomadas bajo las limitaciones de un año concreto, y esas decisiones siguen apareciendo hoy en el peso de tus páginas.

Esta es la versión práctica de ese experimento: qué hace de verdad cada formato con tus píxeles, qué navegadores lo decodifican a mediados de 2026, qué está sirviendo realmente la web y, al final, una tabla que puedes pegar en la wiki de tu equipo.

Los candidatos, uno a uno

JPEG (1992). El mecanismo: divide la imagen en bloques de 8 × 8, transforma cada bloque en frecuencias con la transformada discreta del coseno y luego cuantiza el detalle fino hacia cero siguiendo un modelo de la visión humana. Fortalezas: decodifica en cualquier dispositivo fabricado desde mediados de los 90, codifica rápido y es excelente con fotos de tono continuo. Debilidades: sin transparencia, sin animación, ringing visible alrededor de bordes nítidos y texto, y una calidad que se degrada en cascada con cada regrabado. Sirve para fotografías y para cualquier cosa que tenga que abrirse en todas partes sin excepción.

PNG (1996). El mecanismo: totalmente sin pérdida. Cada línea de la imagen se filtra con un predictor y luego se empaqueta con DEFLATE, la misma pareja de LZ77 más Huffman que lleva gzip dentro. Fortalezas: salida exacta píxel a píxel, alfa completo, soporte universal. La debilidad son las fotos: el ruido del sensor derrota al predictor, así que una foto de 12 MP comprime quizá 1,5:1 sobre los píxeles brutos. Sirve para capturas de pantalla, capturas de interfaz, diagramas y cualquier cosa con texto o color plano.

GIF (1987). El mecanismo: compresión LZW sobre una paleta de como máximo 256 colores, con varios fotogramas empaquetados en un solo archivo. La única fortaleza que le queda es una animación que se reproduce en todas partes, incluidos los clientes de correo que no soportan los formatos modernos. Las debilidades son todo lo demás: 256 colores, transparencia de un bit y archivos mucho más grandes que el vídeo equivalente. Sirve para memes y pequeños bucles de interfaz.

SVG (2001). El mecanismo: ninguno, en el sentido raster. SVG es XML que describe formas, trazados y degradados, y el renderizador dibuja los píxeles a la resolución que la pantalla necesite. Fortalezas: independiente de la resolución, minúsculo para arte geométrico, estilizable con CSS. Debilidades: solo funciona con contenido genuinamente vectorial, y los archivos patológicos con miles de nodos y filtros pesados pueden costar más que un bitmap. Sirve para logotipos, iconos, gráficos y diagramas.

WebP (2010). El mecanismo: el modo con pérdida toma prestada la predicción intraframe del códec de vídeo VP8, y el modo sin pérdida usa predicción espacial más referencias hacia atrás al estilo LZ77. Fortalezas: ambos modos en un mismo formato, alfa en el modo con pérdida, animación y archivos entre un 25 y un 34% más pequeños que JPEG a calidad equivalente, según el propio estudio de Google. Debilidades: un límite estricto de 16383 × 16383 píxeles y un codificador que gasta más CPU que libjpeg. Sirve para casi todo, y por eso se convirtió en la vía de actualización por defecto de JPEG, PNG y GIF en la web.

AVIF (2019). El mecanismo: fotogramas fijos del códec de vídeo AV1, envueltos en el contenedor HEIF. Fortalezas: la mejor compresión con pérdida que se puede servir en un navegador, en torno a un 50% más pequeña que JPEG a calidad equivalente en las pruebas de Netflix de 2020, además de color de 10 y 12 bits, HDR, alfa y animación. Debilidades: codificar es de verdad lento, no hay renderizado progresivo (la imagen aparece de golpe o no aparece), y los ajustes de calidad muy bajos difuminan la textura de una forma que el bloqueo de JPEG no produce. Sirve para fotografías e imágenes hero, donde más importa el tamaño del archivo.

HEIC (2015). El mecanismo: fotogramas fijos de HEVC, también en un contenedor HEIF. Fortalezas: compresión a la altura de AV1 y formato de captura por defecto en todos los iPhone desde 2017. La debilidad es legal, no técnica: HEVC viene envuelto en pools de patentes, y todos los fabricantes de navegadores excepto Apple se negaron a pagar. Pertenece al carrete de la cámara, no a la web.

JPEG XL (2021). El mecanismo: dos motores bajo el mismo techo, VarDCT para el trabajo con pérdida y un modo modular para el sin pérdida, más un truco que ningún otro formato tiene. Puede recomprimir un JPEG existente sin pérdida hasta dejarlo en torno al 80% de su tamaño original, con los píxeles bit a bit incluidos. Fortalezas: decodificación progresiva, excelentes ratios sin pérdida, fotografía de alta fidelidad. La debilidad es la adopción, que es sobre todo una cuestión de política de navegadores y se trata más abajo. Sirve para pipelines de fotografía y archivos, y en dispositivos Apple, para la web.

Soporte en navegadores, mediados de 2026

Versiones en las que cada formato se activó por defecto, según datos de caniuse:

Hay tres detalles de esta tabla que merecen comentarse. AVIF en iOS llegó técnicamente en Safari 16.0 pero sin animación; es en 16.4 donde aterriza el soporte completo, tanto en macOS como en iOS. Edge sirvió AVIF años después que Chrome a pesar de ser Chromium, porque Microsoft mantuvo el decodificador desactivado más tiempo que Google. Y la fila de JPEG XL esconde una historia curiosa, que tiene su propia sección más abajo.

Cobertura global, según las cifras de caniuse de 2026: WebP ronda el 97%, AVIF el 93 a 94%. JPEG y PNG están efectivamente al 100%, y es poco probable que eso cambie.

La jerarquía de compatibilidad

Agrupados por alcance, los formatos se reparten en cinco niveles.

El nivel uno es el conjunto universal: JPEG, PNG, GIF y SVG. Decodifican en todos los navegadores, todos los clientes de correo, todas las vistas previas del sistema operativo y todos los kioscos de hace una década. Si un archivo tiene que abrirse sin falta, se sirve en uno de estos cuatro.

El nivel dos es WebP, en solitario. El último gran resistente fue Safari, y Safari 14 cerró esa brecha en septiembre de 2020. Lo que queda son instalaciones de Internet Explorer y WebViews de Android muy antiguos. Para un sitio web, a diferencia de un correo, WebP lleva unos cinco años siendo una opción segura por defecto.

El nivel tres es AVIF. Chrome lo tuvo en 2020, Firefox en 2021, Safari en 2022 (soporte completo en marzo de 2023 con 16.4) y Edge lo activó por defecto en enero de 2024. Desde principios de 2024, todos los motores importantes decodifican AVIF de fábrica. El puñado de puntos que falta son iPhones antiguos y flotas de Windows sin gestionar, que es exactamente para lo que existen los fallbacks.

El nivel cuatro es JPEG XL, atascado. Apple lo sirve de forma nativa desde Safari 17 en septiembre de 2023. Google retiró el decodificador experimental de Chromium a finales de 2022, con efecto en Chrome 110 en febrero de 2023, y luego dio marcha atrás e integró un decodificador basado en Rust (jxl-rs) que llegó en Chrome 145 en febrero de 2026, todavía tras un flag. Firefox lleva años con un decodificador tras un flag. Así que el soporte de JPEG XL a mediados de 2026 significa todos los usuarios de Apple más la fracción mínima de usuarios de Chrome y Firefox que activan flags, un grupo demasiado pequeño como para construir sobre él.

El nivel cinco es HEIC: Safari 17 en plataformas Apple, nada más en ningún sitio. Eso es menos un nivel que un ecosistema de un solo fabricante.

Qué sirve la web de verdad

El soporte no es el uso. El Web Almanac de HTTP Archive rastrea millones de páginas reales y cuenta lo que sirven, y la edición de 2024 (la última con datos completos de medios) se lee como un glaciar en movimiento. JPEG seguía siendo el formato más común con el 32% de todas las imágenes, pero eso son ocho puntos enteros menos que el 40% de 2022. WebP recogió tres de esos puntos hasta llegar al 12%. SVG ganó unos dos. AVIF alcanzó aproximadamente el 1%, que suena a error de redondeo hasta que lo lees en relativo: un crecimiento de casi 4× en dos años. ICO se quedó con el 1,3%, y casi todo corresponde a favicons. Y GIF, con 37 años a cuestas, ganó de algún modo un punto.

¿Por qué se mueve tan despacio? Tres fricciones hacen casi todo el trabajo. La caché de las CDN: las imágenes viven en el edge indexadas por URL, y cambiar de formato significa invalidar cachés y recodificar bibliotecas enteras. Los dispositivos antiguos: el gráfico de soporte dice 97%, pero ese 3% que falta se concentra en Android baratos y flotas corporativas, y algunos sitios no pueden permitirse perder ni una sola venta por una imagen rota. La inercia de las herramientas: el CMS genera miniaturas JPEG porque siempre lo ha hecho, la herramienta de diseño exporta PNG porque ese es el botón grande, y cambiar el valor por defecto significa tocar un pipeline de build que no es de nadie.

También está el coste de codificación. La ventaja de compresión de AVIF se paga en CPU en el momento de codificar, y por eso las CDN de imágenes lo cobran y por eso los equipos previsores pregeneran AVIF en el build o en la subida en vez de hacerlo al vuelo.

Hacia dónde va esto

AVIF es la apuesta más segura para los próximos años. Es libre de regalías por diseño (la Alliance for Open Media se fundó en 2015 por Amazon, Cisco, Google, Intel, Microsoft, Mozilla y Netflix precisamente para escapar de los pools de patentes estilo HEVC), maneja con pérdida y sin pérdida en una misma especificación, soporta HDR y ya cruzó el umbral de soporte donde una cadena de fallbacks casi no cuesta nada. Los costes reales son el tiempo de codificación y la ausencia de decodificación progresiva. La pregeneración resuelve el primero; el segundo es un intercambio razonable.

JPEG XL merecía un resultado mejor del que tuvo. Por mérito técnico es el formato más completo jamás estandarizado: decodificación progresiva, el mejor modo sin pérdida, fotografía de gran profundidad de bits y recompresión sin pérdida de todo el corpus de JPEG existente. Google lo retiró de Chromium alegando interés insuficiente del ecosistema, y la petición de restauración se convirtió en uno de los issues con más estrellas de la historia del tracker de Chromium. Tres años después Google revirtió la decisión, pero para entonces la ventana de adopción ya se había cerrado en gran parte. Mientras JPEG XL vivía en el exilio, AVIF se hizo con las integraciones de CDN, los plugins de CMS y las casillas marcadas por defecto. JPEG XL sobrevivirá como el favorito de los archivistas y como ciudadano de primera en los dispositivos Apple. Tenía los argumentos técnicos para la adopción mayoritaria y aun así no la consiguió.

HEIC no se convertirá en un formato web. La razón no tiene nada que ver con la calidad. Decodificar HEVC exige licencias de patentes que los fabricantes de navegadores gratuitos llevan una década negándose a pagar, y la web funciona con tecnología libre de regalías. Un formato que tres de los cuatro motores principales no decodifican no es un formato web; es un problema de exportación que se resuelve en la frontera.

La técnica de transición, mientras tanto, está bien establecida, y tiene dos formas. Negociación de contenido en el servidor: el navegador envía una cabecera Accept con lo que sabe decodificar, y el servidor o la CDN elige la mejor variante para la misma URL. En el cliente: el elemento <picture>, que enumera candidatos y deja que el navegador tome el primero que entienda:

<picture>
  <source srcset="hero.avif" type="image/avif" />
  <source srcset="hero.webp" type="image/webp" />
  <img src="hero.jpg" alt="Team photo" width="1600" height="900" />
</picture>

El <img> del final es el fallback universal, así que nada se rompe en ningún sitio. Así es como sirves AVIF al 93% y JPEG al resto sin mantener dos sitios.

La tabla de decisión

Una nota sobre los favicons, porque la fila de la tabla deja fuera algunos detalles. Los navegadores modernos aceptan favicons en PNG e incluso en SVG, pero ICO sigue siendo el único formato que entienden todos los crawlers, lectores RSS y pestañas de navegadores antiguos, y un archivo ICO puede empaquetar varios tamaños en un solo contenedor. Si tu logotipo vive ahora mismo en otro formato, JPG a ICO, WebP a ICO y PNG a ICO generan un ICO multiresolución correcto directamente en tu navegador.

Convertir entre formatos

La mayoría de las tareas de conversión se deducen de las secciones anteriores. La más común con diferencia es sacar un HEIC de un iPhone y meterlo en algo que el resto del mundo pueda abrir. HEIC a JPG es la opción correcta para compartir, ya que HEIC ya es con pérdida y JPEG evita que el daño se acumule. HEIC a PNG congela el estado actual para editar, y HEIC a WebP tiene sentido cuando el destino es un sitio web.

Luego está el triángulo JPEG, PNG, WebP. Meter un JPEG en un flujo de diseño: JPG a PNG, no porque gane calidad (no puede), sino porque deja de perderla. Aligerarlo para la web: JPG a WebP. En la dirección contraria, para software antiguo: WebP a JPG y WebP a PNG. Una captura PNG camino de una galería de fotos: PNG a JPG, o PNG a WebP cuando quieres archivos más pequeños conservando la transparencia. Si heredas escaneos BMP sin comprimir, BMP a JPG, BMP a PNG y BMP a WebP son todos mejores que mandar por correo reliquias de varios megabytes. Hasta los documentos llegan a la misma bifurcación: PDF a JPG para páginas fotográficas, PDF a PNG cuando el texto tiene que quedar nítido, y PDF a WebP cuando la página va camino de la web.

Cada una de esas herramientas ejecuta la conversión localmente en tu navegador, así que el archivo no sale nunca de tu dispositivo.

Los formatos cambian. La regla no: ajusta el códec al contenido, y convierte cuando el contenido cambia de función.