JPG vs PNG vs WebP vs AVIF: elegir el formato de imagen correcto en 2026

Si publicas imágenes en la web, el formato que elijas tiene más impacto en el peso de la página que casi cualquier otra decisión aislada. Una imagen principal de 4 MB frente a una de 180 KB es la diferencia entre un sitio que se siente instantáneo y uno que se arrastra en un Android de gama media sobre una conexión 4G inestable. En 2026 tenemos cuatro contendientes principales que merecen atención: el venerable JPG, el sin pérdidas PNG, el ahora universal WebP y el cada vez más maduro AVIF.

Esta guía explica cómo funciona cada formato por dentro, de dónde vienen los ahorros de bytes, qué compromisos aceptas y una recomendación clara de cuándo usar cuál. Al terminarla deberías poder responder a la pregunta "¿cuál es el mejor formato de imagen para la web en 2026?" sin titubear, y saber exactamente qué hacer cuando un artista te entrega una captura PNG de 28 MB a las 5 de la tarde de un viernes.

El reparto

JPG (a veces escrito JPEG) se estandarizó en 1992 y sigue siendo el formato en el que disparan la mayoría de las cámaras. Usa una transformada discreta del coseno (DCT) sobre bloques de 8x8, cuantiza los coeficientes de frecuencia y codifica el resultado con Huffman. Es con pérdida por diseño y no tiene canal alfa, pero es rápido, barato de decodificar y compatible con literalmente cualquier dispositivo construido en los últimos treinta años.

PNG llegó en 1996 como sustituto libre de patentes de GIF. Usa DEFLATE (el mismo algoritmo que zip y gzip) sobre filtros de fila opcionales, así que es totalmente sin pérdidas. PNG soporta un canal alfa real de 8 bits, paletas indexadas e incluso color de 16 bits por canal. El precio que pagas es el tamaño del archivo: el contenido fotográfico se comprime mal con DEFLATE.

WebP fue publicado por Google en 2010 y alcanzó soporte completo entre navegadores en torno a 2020. El WebP con pérdida usa codificación intra-frame de VP8 (los mismos modos de predicción que el códec de vídeo VP8) en lugar de un DCT plano. El WebP sin pérdidas usa VP8L, un formato propio con trucos de caché de color y transformadas predictoras. WebP soporta alfa en ambos modos, además de animación.

AVIF es el perfil para imágenes fijas de AV1, el códec de vídeo finalizado en 2018 y enviado por prácticamente todo el mundo para 2024. Usa bloques de predicción mucho más grandes e inteligentes, más opciones de transformada y un codificador de entropía enormemente mejor que el de VP8. AVIF soporta hasta 12 bits de color, alfa, HDR y animación.

Cómo funciona realmente la compresión

JPG divide la imagen en bloques de 8x8, aplica una DCT a cada bloque y luego divide los coeficientes resultantes por una matriz de cuantización. Las frecuencias altas se aplastan más que las bajas porque el ojo humano es menos sensible a los detalles finos. Los ajustes de menor calidad simplemente multiplican esa matriz de cuantización por un escalar mayor. Por eso los artefactos de JPG se ven como un anillado en bloques alrededor de los bordes duros: el codificador literalmente no puede permitirse mantener los coeficientes de alta frecuencia que describen el borde.

PNG no hace ninguna compresión perceptual. Cada fila de píxeles recibe un prefijo de filtro de un byte (None, Sub, Up, Average o Paeth) que predice cada píxel a partir de sus vecinos, y luego DEFLATE comprime los residuos. Si tu imagen es una fotografía, los residuos siguen siendo ruido de alta entropía y ahorras muy poco. Si es una captura llena de colores sólidos repetidos y bordes nítidos, los ahorros son enormes.

El WebP con pérdida toma prestada la predicción espacial intra de VP8: cada bloque de 4x4 o 16x16 se predice a partir de píxeles vecinos ya decodificados usando uno de diez modos de predicción, y solo el residuo se transforma y cuantiza. Una mejor predicción significa residuos más pequeños, lo que significa menos bits. El WebP sin pérdidas (VP8L) va más allá con una caché de color propia, transformaciones de paleta y un codificador de entropía adaptable al contexto.

AVIF utiliza, en esencia, un codificador moderno de keyframes de vídeo entero. Los tamaños de bloque van de 4x4 hasta 128x128, las transformadas incluyen DCT, ADST e identidad en varios tamaños, y existen más de 56 modos de predicción intra, incluidos predictores direccionales con granularidad angular fina. El codificador aritmético al estilo CABAC empaqueta significativamente más información por bit que las tablas de Huffman de JPG. El resultado son archivos aproximadamente un 50 % más pequeños que los JPG a la misma calidad visual, a costa de una codificación mucho más pesada.

Tamaño de archivo de un vistazo

Same 4000x3000 photo (a daylight landscape, no transparency):
JPG  (q=85)   ->  1,180 KB
JPG  (q=92)   ->  1,940 KB
PNG  (24-bit) -> 12,420 KB
WebP (q=85)   ->    810 KB
WebP (lossless) -> 9,860 KB
AVIF (q=60)   ->    495 KB
AVIF (q=80)   ->    760 KB

Same 1920x1080 UI screenshot (flat colours, sharp text):
JPG  (q=92)   ->    410 KB  (text fringes visibly)
PNG  (8-bit indexed) ->  92 KB
PNG  (24-bit) ->    280 KB
WebP (lossless) ->  74 KB
AVIF (lossless) ->  88 KB

Dos conclusiones de estas cifras. Primera, en fotografías naturales AVIF es aproximadamente entre un 40 y un 60 % más pequeño que JPG y entre un 30 y un 40 % más pequeño que WebP a calidad percibida equiparable. Segunda, en contenido sintético como capturas y exportaciones de interfaz, WebP sin pérdidas suele ganar de calle, con PNG-8 muy de cerca cuando la paleta encaja.

Soporte de navegadores en 2026

JPG y PNG: 100 %. No hay nada que discutir. Funcionan en todo lugar donde exista un navegador, incluidas tabletas Android de hace diez años y WebViews integradas que ya habías olvidado.

WebP: efectivamente el 100 % del tráfico de navegadores. Safari añadió soporte en iOS 14 y macOS Big Sur allá por 2020, Chrome y Firefox lo tienen desde mucho antes e incluso la mayoría de los navegadores in-app ya lo decodifican. A fecha de 2026, servir WebP sin un fallback a JPG ya no es temerario para un sitio de consumo típico.

AVIF: aproximadamente entre el 95 y el 97 % de los navegadores en 2026. Chrome, Edge, Firefox, Safari (16.4+) y las principales WebViews de Android lo decodifican. El hueco restante es sobre todo Android muy antiguo, algunas WebViews integradas en smart TVs viejas y una larga cola de dispositivos corporativos bloqueados. Para un sitio de cara al público, AVIF con un fallback a WebP o JPG es un valor por defecto seguro.

Transparencia, animación y profundidad de color

JPG no tiene canal alfa en absoluto. Si necesitas cualquier tipo de transparencia, no puedes usarlo. Esta es la razón más común por la que los diseñadores echan mano de PNG cuando no deberían.

PNG ofrece un canal alfa real de 8 bits y soporta hasta 16 bits por canal de color, lo que lo hace útil para intermedios de alta precisión en pipelines gráficos. No hay animación en el PNG estándar; APNG existe, pero el soporte es desigual fuera de pegatinas y emojis.

WebP soporta alfa tanto en modo con pérdida como sin pérdidas y tiene un buen soporte de animación significativamente más eficiente que el GIF animado. La profundidad de color es de 8 bits por canal, lo que está bien para casi todo el contenido web.

AVIF soporta alfa, animación, color de 10 y 12 bits, gamas amplias y funciones de transferencia HDR. Si publicas fotografía HDR o arte de gama amplia, AVIF es actualmente el único formato web mainstream capaz de transportar los datos con fidelidad.

Decodificación por hardware y energía

La decodificación de JPG es tan barata en el hardware moderno que en realidad no importa; incluso un teléfono de 2015 decodifica JPG más rápido de lo que la pantalla puede mostrarlos. La decodificación de PNG es más pesada por píxel porque DEFLATE no es paralelizable, pero las cargas útiles de PNG suelen ser más pequeñas por imagen en casos tipo captura, así que en la práctica se equilibra.

La decodificación de WebP con pérdida usa la misma vía de silicio VP8 que los chips móviles tienen desde hace más de una década. La decodificación es rápida y eficiente energéticamente. La decodificación de WebP sin pérdidas se hace por software en la mayoría de los chips, pero sigue siendo asumible.

AVIF es donde la cosa se pone interesante. La decodificación por software es genuinamente más pesada que la de JPG o WebP, ocasionalmente con un factor de tres a cinco en una sola imagen. La buena noticia es que la mayoría de los teléfonos enviados después de 2022 tienen decodificación AV1 por hardware por la que el navegador puede enrutar las imágenes fijas; en esos dispositivos AVIF es de hecho tan rápido como JPG o más. En portátiles más antiguos sin silicio AV1, decodificar una pared de miniaturas AVIF puede aparecer en los perfiles de CPU, así que úsalo con criterio y apóyate en el marcado de imágenes responsivas para que siempre se decodifique la variante más pequeña.

Cuándo usar cada uno: la versión corta

• Usa JPG para fotografías cuando necesites la máxima compatibilidad absoluta y no quieras mantener varias variantes. Una calidad entre 82 y 88 es el punto óptimo habitual.
• Usa PNG para capturas, exportaciones de interfaz, logos con bordes duros y cualquier cosa que necesite transparencia sin pérdidas en un apuro. Prefiere PNG indexado de 8 bits cuando la paleta encaje.
• Usa WebP como formato web por defecto en 2026. WebP con pérdida para fotos, WebP sin pérdidas para recursos de interfaz e iconos que antes habrían sido PNG.
• Usa AVIF cuando el ancho de banda y los Core Web Vitals son lo que más importa, cuando estés sirviendo contenido HDR o de gama amplia, o cuando quieras la imagen LCP más pequeña posible. Empareja siempre con un fallback a WebP o JPG mediante el elemento picture.
• Evita GIF por completo. WebP y AVIF animados son más pequeños y se ven mejor con el mismo presupuesto de bytes.

Un flujo de trabajo de conversión práctico

La mayoría de los equipos no necesitan un pipeline de construcción elaborado para aprovechar los formatos modernos. El flujo mínimo viable es sencillo: conserva la exportación original de la cámara o la herramienta de diseño como fuente de verdad y luego genera variantes JPG, WebP y AVIF en el momento del despliegue. Para conversiones puntuales, una CLI hace el trabajo en segundos.

# Convert a single photo to all three modern variants
cwebp -q 85 hero.jpg -o hero.webp
avifenc --min 20 --max 30 -s 6 hero.jpg hero.avif

# Use the picture element so the browser picks the best one it understands
# <picture>
#   <source srcset="hero.avif" type="image/avif">
#   <source srcset="hero.webp" type="image/webp">
#   <img src="hero.jpg" alt="..." width="1600" height="900">
# </picture>

Si no quieres instalar herramientas de línea de comandos y solo tienes un puñado de imágenes, Multilities ofrece un conversor de imágenes en el navegador en /tools/image-convert que maneja JPG, PNG, WebP y AVIF en cualquier dirección sin subir tus archivos a ningún sitio; todo corre en tu pestaña. Para exprimir bytes extra de un JPG o PNG existente sin cambiar de formato, /tools/image-compress los recodifica a la calidad que elijas y te muestra los conteos de bytes antes y después.

WebP vs PNG: la pregunta que no se muere

La confusión más común en 2026 sigue siendo WebP vs PNG. La respuesta corta: el WebP sin pérdidas es estrictamente mejor que PNG para casi todos los casos de uso web. Es más pequeño, soporta el mismo canal alfa y todos los navegadores que te importan lo decodifican. Las únicas razones para seguir usando PNG hoy son herramientas downstream que no aceptan WebP (algunas redes publicitarias, algunos plugins de CMS heredados, algunos flujos de impresión) y el hecho de que PNG es el formato de intercambio de facto entre diseñadores.

Si estás construyendo un producto nuevo desde cero, configura tu pipeline de recursos por defecto a WebP sin pérdidas para la interfaz y AVIF con pérdida para fotos, y solo recurre a PNG y JPG cuando algo se niegue a aceptar el formato moderno.

Trampas comunes

• No recodifiques un JPG como otro JPG a mayor calidad esperando que el archivo se vea mejor. La cuantización original ya descartó información; solo conseguirás un archivo más grande.
• No guardes capturas de pantalla como JPG. El anillado en bloques alrededor del texto es inconfundible e irreparable. Usa PNG o WebP sin pérdidas.
• Vigila el perfil de color. Los codificadores AVIF y WebP modernos preservan los perfiles ICC por defecto; las herramientas antiguas los eliminan y tu imagen cambiará de matiz en pantallas de gama amplia.
• Prueba la escala de calidad de tu codificador AVIF. Diferentes codificadores usan convenciones distintas: libavif usa una calidad de 0 a 100, mientras que avifenc usaba históricamente un cuantizador min/max de 0 a 63 donde menos es mejor.
• Si usas una CDN que recodifica al vuelo, asegúrate de que esté negociando AVIF de verdad mediante la cabecera Accept. Muchas CDN están por defecto solo a WebP a menos que actives un ajuste.

¿Y qué hay de JPEG XL?

JPEG XL es un formato genuinamente bueno, técnicamente competitivo con AVIF y con el truco único de poder transcodificar sin pérdidas los JPG existentes a un tamaño aproximadamente un 20 % menor. A fecha de 2026, Safari lo incluye, Firefox lo soporta detrás de una bandera y Chrome sigue sin habilitarlo por defecto. Hasta que eso cambie, trata a JXL como un formato a vigilar y no como uno para desplegar. AVIF es el formato moderno con soporte cross-browser hoy.

El árbol de decisión de 30 segundos

Si es una fotografía, genera AVIF y WebP, y haz fallback a JPG. Si tiene transparencia o bordes nítidos, genera WebP sin pérdidas y haz fallback a PNG. Si no puedes ejecutar un paso de build, sirve JPG para fotos y PNG para todo lo demás y sigue con tu vida. Los formatos de imagen ya no son un proyecto de investigación en 2026; las respuestas están mayormente asentadas y las herramientas son maduras. Elige el formato correcto, configura un fallback y dedica el tiempo ahorrado a otra cosa.