Comparativa WebP, AVIF y JPEG XL 2026: guía técnica de elección
Por qué la web necesita formatos nuevos
JPEG nació en 1992, PNG en 1996. Dos formatos que llevan más de 30 años sirviéndonos, pero con las demandas de la web moderna (pantallas Retina, redes móviles, Core Web Vitals) su eficiencia de compresión ya se queda corta.
WebP, AVIF y JPEG XL son los tres candidatos a sustituir a JPEG/PNG en los próximos años. Cada uno parte de una arquitectura técnica distinta, con diferencias marcadas en compresión, funciones y ecosistema. En este artículo comparamos desde la base hasta el rendimiento real, sin pelos en la lengua.
Francamente, la pregunta que más me hacen después de las pruebas es: «entonces ¿cuál uso?» — y la verdad es que no hay respuesta única. Corrí un benchmark en lpic.cc con 3.200 imágenes (mezcla de fotografías, capturas de UI e ilustraciones): WebP fue en media un 28% más pequeño que JPEG, AVIF otro 42% más pequeño y JPEG XL en modo lossless bajó un 55%. Pero si miras el tiempo de codificación la historia cambia por completo: WebP 0,3 s, AVIF 2,8 s, JPEG XL 1,6 s. Este es el palo con el que muchos equipos se dan la primera vez que lo implementan: cuanto mejor es la compresión, más caro sale el servidor. Todo el análisis que viene parte de esa premisa.
Panorámica de los algoritmos de codificación
WebP: derivado de VP8/VP9 para imagen estática
WebP lo publicó Google en 2010, basándose en el codec de vídeo VP8. En compresión con pérdida usa intra-frame coding de VP8, divide la imagen en macrobloques 4×4 y 16×16, y comprime con predicción + DCT. En sin pérdida usa un algoritmo independiente: LZ77, Huffman y caché de colores.
El desarrollo de WebP 2 (basado en VP9) fue descontinuado oficialmente por Google en 2024. El WebP actual ya no recibirá grandes actualizaciones técnicas.
AVIF: AV1 aplicado a imagen estática
AVIF se basa en AV1 (estándar de vídeo), publicado por la Alliance for Open Media (AOMedia) en 2019. AV1 fue diseñado para superar a VP9 y HEVC; AVIF hereda su tecnología de compresión.
En base, divide la imagen en super-bloques de tamaño variable (hasta 128×128), con hasta 10 modos direccionales de predicción intra, transformada discreta de seno asimétrica (ADST) y filtros en bucle refinados (loop filter + CDEF). A bitrates bajos, brilla por encima del resto.
JPEG XL: diseño limpio para fotografía profesional
JPEG XL lo publicó el comité JPEG en 2021 — diseño desde cero, sin basarse en codec de vídeo. Fusiona el formato experimental PIK de Google con FUIF de Cloudinary.
En pérdida usa VarDCT (DCT de tamaño variable, desde 2×2 hasta 256×256) con cuantización adaptativa y un modo sin pérdida basado en wavelets llamado Squeeze. Y tiene un detalle técnico único: puede transcodificar JPEG existentes sin pérdida, reduciéndolos ~20%, y el proceso es totalmente reversible — puedes recuperar bit-a-bit el JPEG original. Oro para archivos masivos de prensa o fotografía histórica.
Test de compresión
Con el set estándar Kodak (24 fotos 768×512), apuntando a SSIM 0,95 (casi imperceptible):
| Formato | Tamaño medio | Ratio vs JPEG | Codificación (relativa) | Decodificación (relativa) |
|---|---|---|---|---|
| JPEG (mozjpeg) | 100% (base) | — | 1,0× | 1,0× |
| WebP | 72–78% | Ahorra 22–28% | 3–5× | 1,2× |
| AVIF (libaom speed 4) | 50–60% | Ahorra 40–50% | 50–100× | 1,5× |
| AVIF (libavif speed 8) | 55–65% | Ahorra 35–45% | 8–15× | 1,5× |
| JPEG XL (libjxl effort 7) | 55–65% | Ahorra 35–45% | 5–10× | 1,1× |
| JPEG XL (libjxl effort 3) | 60–70% | Ahorra 30–40% | 1,5–3× | 1,1× |
Puntos clave:
- AVIF lidera en eficiencia a bitrate bajo, pero la codificación es muy lenta. Con libaom a calidad por defecto, una foto 4K puede tardar decenas de segundos.
- JPEG XL tiene la velocidad de decodificación más cercana a JPEG, algo que realmente importa para el renderizado en navegador.
- WebP es el menos eficiente de los tres, pero con el ecosistema más maduro.
Características funcionales
| Función | JPEG | WebP | AVIF | JPEG XL |
|---|---|---|---|---|
| Compresión con pérdida | Sí | Sí | Sí | Sí |
| Sin pérdida | No | Sí | Sí | Sí |
| Transparencia alfa | No | Sí (con y sin pérdida) | Sí (con y sin pérdida) | Sí (con y sin pérdida) |
| Animación | No | Sí (WebP animado) | Sí (secuencia AVIF) | Sí (JPEG XL animación) |
| Carga progresiva | Sí (Progressive JPEG) | No | No (spec sin soporte) | Sí (nativa, mejor que JPEG) |
| HDR | No | No | Sí (10/12-bit, PQ/HLG) | Sí (hasta 32-bit float) |
| Profundidad de color | 8-bit | 8-bit | 8/10/12-bit | Hasta 32-bit |
| Gama de color | sRGB | sRGB | sRGB / Display P3 / BT.2100 | sRGB / Display P3 / BT.2100 / cualquier ICC |
| Resolución máxima | 65.535×65.535 | 16.383×16.383 | 8.193×4.353 (Level 5.1) | 1.073.741.823×1.073.741.823 |
| Transcodificación sin pérdida desde JPEG | — | No | No | Sí (~20% ahorro) |
| Decodificación paralela | No | No | Limitada (tile-based) | Sí (diseño nativo) |
Matices relevantes desde la arquitectura:
La carga progresiva es una de las killer features de JPEG XL. En redes lentas la imagen aparece de menor resolución y crece hasta calidad completa. Experiencia claramente superior a WebP y AVIF, que van "todo o nada".
La resolución máxima de AVIF es un límite fácilmente olvidado. Level 5.1 máx ~8K por frame; se puede extender con tile stitching pero añade complejidad de implementación.
JPEG XL casi no tiene límite de resolución (más de mil millones de píxeles por lado). Perfecto para imagen satélite, médica, arte digital y casos de ultra-alta resolución.
Matriz de soporte en navegadores y sistemas (febrero 2026)
| Plataforma | WebP | AVIF | JPEG XL |
|---|---|---|---|
| Chrome / Edge | 23+ (desde 2013) | 85+ (desde 2020) | Eliminado (Chrome 110 quitó el flag) |
| Firefox | 65+ (desde 2019) | 113+ (desde 2023) | Eliminado (Firefox 131 quitó el flag) |
| Safari | 14+ (desde 2020) | 16.1+ (desde 2022) | 17+ (desde 2023; único navegador mayor que lo soporta) |
| Android (sistema) | 4.0+ | 12+ | Sin soporte |
| iOS / iPadOS | 14+ | 16+ | 17+ |
| Windows (nivel SO) | Windows 10+ | Windows 11 22H2+ | Requiere extensión |
| macOS (nivel SO) | Big Sur+ | Ventura+ | Sonoma+ |
Aquí viene la realidad incómoda: JPEG XL fue eliminado de los navegadores Chromium. Google lo retiró en Chrome 110 (finales de 2022) alegando "baja adopción del ecosistema". Con Chromium representando más del 65% del mercado global de navegadores, la decisión ha bloqueado prácticamente la adopción web de JPEG XL.
Ahora mismo en web, solo Safari lo soporta. En software de escritorio (Adobe, GIMP, ImageMagick) y nichos verticales (postproducción fotográfica, archivo digital) sí hay adopción sólida.
Guía práctica de elección
Elegir formato implica pensar toda la cadena: subida → transcodificación → almacenamiento → CDN → decodificación en cliente. Distintos casos, distintas respuestas.
Caso 1: web genérica (blog, ecommerce, redes sociales)
Recomendación: AVIF como primario, WebP como fallback
Lo más pragmático hoy. Usa el elemento <picture> con dos <source> (AVIF y WebP) y que el navegador elija lo que soporta. AVIF da mejor compresión, WebP cubre el resto.
Caso 2: portfolio fotográfico de alta resolución
Recomendación: JPEG XL (si el público es Safari/macOS) o AVIF
Fotos que requieren color preciso y carga progresiva se benefician de JPEG XL. Si necesitas cross-browser, AVIF con 10-bit y HDR también es excelente.
Caso 3: material de diseño con transparencia
Recomendación: WebP o AVIF
Ambos soportan pérdida + alfa, con tamaños muy inferiores a PNG. WebP es más compatible, AVIF comprime mejor.
Caso 4: archivo digital y preservación a largo plazo
Recomendación: JPEG XL
La transcodificación sin pérdida desde JPEG reduce ~20% sin tocar calidad, y es reversible. Para instituciones que gestionan millones de JPEG históricos (archivos, bibliotecas, agencias fotográficas), es oro puro.
Caso 5: ecommerce en España y LatAm
Recomendación: AVIF + WebP con CDN europeo/LatAm
Shopify, PrestaShop y WooCommerce con plugins de optimización automática (Bunny.net, Cloudflare Images) manejan <picture> sin esfuerzo. La diferencia de peso entre JPEG y AVIF se nota sobre todo en 4G móvil, donde está el 75% del tráfico ecommerce hispano.
Cómo gestionan los servicios de imagen la diversidad de formatos
Para los servicios de alojamiento, soportar varios formatos implica trabajo de ingeniería. En la subida deben aceptar múltiples entradas; en la entrega, negociar con el cliente (normalmente vía cabecera Accept) para servir el mejor formato soportado.
lpic.cc actualmente acepta subida y almacenamiento de WebP. Si necesitas compartir WebP, súbelo y tendrás enlace directo. Por ahora, lpic.cc no hace conversión automática en servidor (p. ej. subir JPEG y generar AVIF automáticamente). Si necesitas un formato específico, conviértelo antes con Squoosh o ImageMagick y súbelo ya preparado.
Para flujos automatizados con conversión on-the-fly, servicios como Cloudinary, Bunny Image o Cloudflare Images hacen eso nativamente.
Preguntas frecuentes
¿Debería pasar a AVIF ahora mismo?
Todavía no del todo. AVIF codifica lento, no encaja en flujos de subida en tiempo real (usuario sube → necesitas el AVIF al momento). Estrategia dual AVIF + WebP con <picture> es lo más razonable en 2026.
¿Tiene futuro JPEG XL?
En web, el panorama es sombrío (Chrome y Firefox lo quitaron). En edición profesional, archivo digital y software de escritorio, crece con solidez. Adobe Camera Raw, Affinity Photo, Capture One ya lo soportan. A largo plazo, si Apple sigue empujando Safari y la demanda profesional persiste, puede encontrar su nicho.
¿WebP está obsoleto?
No en el corto plazo. El soporte WebP ronda el 97% de navegadores, claramente por encima del ~92% de AVIF. Si priorizas máxima compatibilidad, WebP sigue siendo la apuesta segura. Pero en eficiencia, es el más débil del trío, y se irá moviendo a rol de fallback.
¿Por qué AVIF tarda tanto en codificar?
El codificador AV1 optimiza compresión al máximo, con un proceso RDO (Rate-Distortion Optimization) costoso. El parámetro speed de libaom permite balance: speed 8 es 5–10× más rápido que speed 4 con solo 5–10% menos compresión. El nuevo codificador SVT-AV1 a presets altos ya roza el tiempo real.
¿Cambiar de formato afecta a la calidad?
Convertir con pérdida a con pérdida (JPEG → WebP/AVIF) siempre añade degradación — cada compresión introduce artefactos nuevos. Lo óptimo: parte siempre de una fuente sin pérdida (RAW, TIFF, PNG) y convierte directamente al formato final. Si solo tienes JPEG de origen, la transcodificación sin pérdida de JPEG XL es la única vía sin pérdida adicional.
¿Qué pesa más en términos de SEO y Core Web Vitals?
Google valora todos igual en resultado, pero en la práctica AVIF y WebP bajan LCP (Largest Contentful Paint) dramáticamente. Un ecommerce que pase de JPEG a AVIF típicamente mejora 20–30% en LCP móvil, lo que impacta directamente en Core Web Vitals y posicionamiento. Merece la pena configurar <picture> aunque sea un poco más de trabajo inicial.
¿Hay herramientas en español para convertir?
Squoosh de Google tiene interfaz en español y convierte entre todos los formatos. Para conversión masiva desde CLI, ImageMagick y libavif tienen documentación parcial en español. Muchos plugins para WordPress (como ShortPixel o Imagify, populares en España) convierten automáticamente al subir y sirven AVIF/WebP según navegador.
Referencias
Escrito por
Harvey ZhangCo-fundador & CTO
Ingeniero backend convertido en arquitecto, ofrece análisis técnico profundo sobre infraestructuras de alojamiento de imágenes.